www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - DlangUI Layout Justification

reply Ron Tarrant <rontarrant gmail.com> writes:
Hi all,
It's been a while since I've been on this forum. Hope everyone is 
doing well and have survived the pandemic.

Anyway, a question...

Is there a way to right-justify widgets in a DlangUI Layout?

I'm asking because I've spent the last six months learning to 
build Android apps with the Godot Game Engine, but frankly, it's 
cumbersome and I really miss D. So, I'm looking into D-language 
GUI toolkits that will allow me to make the transition.

And that leads to another question...

Has anyone else been using D to develop for Android? If so, have 
you documented your process/GUI toolkit choices and would you be 
willing to share with me?

With all that said, y'all take care and have a nice day. :)
Mar 09 2023
next sibling parent Ron Tarrant <rontarrant gmail.com> writes:
On Thursday, 9 March 2023 at 10:11:04 UTC, Ron Tarrant wrote:

 Is there a way to right-justify widgets in a DlangUI Layout?
Found it! (In Example 1 [duh]). Still hoping to hear back from someone about the other question.
Mar 09 2023
prev sibling next sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
Another question...

I found LinkButton in the API, but I don't see how/where to give 
it a URL to go to. Anyone know?
Mar 09 2023
parent Ron Tarrant <rontarrant gmail.com> writes:
On Thursday, 9 March 2023 at 10:51:31 UTC, Ron Tarrant wrote:
 Another question...

 I found LinkButton in the API, but I don't see how/where to 
 give it a URL to go to. Anyone know?
Okay, so far I've got Platform.openURL(), but no idea how to use it. Pass it a string, yes, I got that part, but how do I attach it as an action to a LinkButton? Or is attaching actions not the way it's done? I'm off to find out what's written about actions in dlangUI.
Mar 09 2023
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 9 March 2023 at 10:11:04 UTC, Ron Tarrant wrote:

 Has anyone else been using D to develop for Android? If so, 
 have you documented your process/GUI toolkit choices and would 
 you be willing to share with me?
Adam has something for Android: https://github.com/adamdruppe/d_android
Mar 09 2023
parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Thursday, 9 March 2023 at 14:39:06 UTC, ryuukk_ wrote:
 On Thursday, 9 March 2023 at 10:11:04 UTC, Ron Tarrant wrote:

 Has anyone else been using D to develop for Android? If so, 
 have you documented your process/GUI toolkit choices and would 
 you be willing to share with me?
Adam has something for Android: https://github.com/adamdruppe/d_android
Many thanks, ryuukk. I'll check it out.
Mar 09 2023
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 3/9/23 07:09, Ron Tarrant wrote:

 Many thanks, ryuukk. I'll check it out.
I don't know how relevant it is but there is also Hipreme Engine that supports Android: https://forum.dlang.org/thread/fecijdotstuclyzzcque forum.dlang.org Ali
Apr 07 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Friday, 7 April 2023 at 15:52:02 UTC, Ali Çehreli wrote:
 I don't know how relevant it is but there is also Hipreme 
 Engine that supports Android:
I think the question is if you are doing games vs doing other applications. There's some overlap between game and gui, but not actually that much. Both draw things to the screen and accept user input... but even these two things they tend to do quite differently. Guis tend to favor responsiveness. I know, there's people saying "games have to be even more responsive!!!!!" but let me finish: games tend to favor *predictability*. (Some exceptions of course.) A gui will want to respond to input as soon as it can. If I can press a key and see a response on screen in one millisecond, great! Or, on the other hand, if it takes 200 ms... not so great, but I can maybe still live with it. A game will want to respond to input *on a strict schedule*. Responding too fast might break its rules - the world physics aren't infinitely precise and are designed with certain limits in mind. It might also give an unfair advantage to some players over others. Responding too slowly means players will miss their jumps and other frustrating feelings of lack of control. But notice that if something is *predictably* slow, players will get used to it - a lot of things deliberately have some delay according to the rules of the game. Something is only ever "too slow" if it is inconsistently slow. Thus it is common for games to poll input on a timer, whereas guis wait for input on events. Both games and guis draw, but games tend to draw many active things at once, showing a game world that is changing with the passage of time, and guis tend to draw one difference at a time, in response to either a user input or some request finishing. Sure, some guis will do large animations that are similar to how a game works, but these are exceptional circumstances; most the time, a game is drawing to keep the screen in sync with the state of the game world and most the time a gui is idle, waiting for something to happen. That's just the differences in functionality where they overlap. Other things are very different. Games often (but not always) value predictable latency audio, to maintain its a/v sync. Guis, being idle more often than not, can typically defer opening an audio device until they need it, then close it as soon as that effect is done. Most games contain themselves to one large, multi-role window. Guis often use several, with varying roles including temporary single-purpose windows (e.g. popup menus and toolips). Guis need to implement a variety of input patterns that games rarely care about - interprocess drag and drop, copy and paste, ui automation and accessibility apis; guis are more often part of a bigger cooperative whole than just on their own. Games just want to take whatever global input they get into their own self-contained game world, and games are more likely to care about joysticks and gamepads than guis. One library can help with both games and guis but it is unlikely to be a complete solution for either, certainly not both.
Apr 07 2023
parent ShadoLight <ettienne.gilbert gmail.com> writes:
On Friday, 7 April 2023 at 17:13:58 UTC, Adam D Ruppe wrote:
 On Friday, 7 April 2023 at 15:52:02 UTC, Ali Çehreli wrote:
 I don't know how relevant it is but there is also Hipreme 
 Engine that supports Android:
[...] One library can help with both games and guis but it is unlikely to be a complete solution for either, certainly not both.
Wow, what a great comparison, Adam! I've worked on GUIs, but never on games... and often wondered about this. Maybe you can copy+paste the whole thing as a topic on your blog ...? This comparison deserves *not* to fade into oblivion as is the typical fate of most forum discussions.
Apr 10 2023