LDCad 2.0 GUI Thoughts


LDCad 2.0 GUI Thoughts
#1
Hi all,

I'm working on the foundation of what is highly likely to become LDCad 2.0, although currently it has little to nothing to do with LDraw specifics.

While doing this a lot of (boring) fundamental classes and tools need to be (re)written. I've done so for strings, list, etc and the OpenGL gui  engine is next.

Problem is I'm not yet sure on what kind of GUI to give LDCad 2.0. I know many people dislike the 1.x one, but I rather like it myself so I want to improve upon it but keep the basis the same maybe making it very dynamic so it can support different looks.

Anyway in order to write the support classes (window handling etc) I need to know what it should be able to do rendering wise etc.

For this I would like to gather some feedback about the current 1.x gui, in other words what is it people really hate about it or what kind of behavior are they missing.

I'm not talking colors though, as you can already change those in 1.x. One thing I'm thinking about myself is something like the blender gui which should be able to (nearly) mimic the 1.6 look as a default template or something.

Any thoughts/ideas/feedback is welcome.

LDCad 2.0 teaser Big Grin

.png   out.png (Size: 12.98 KB / Downloads: 341)
Reply
RE: LDCad 2.0 GUI Thoughts
#2
I don't have a problem with the interface, but I suspect that the reason "many people dislike the 1.x one" is simply that it's different from what they're used to - in which case you probably can't win with a roll-your-own.

Owen.
Reply
RE: LDCad 2.0 GUI Thoughts
#3
(2017-08-23, 21:06)Owen Dive Wrote: The reason "many people dislike the 1.x one" is simply that it's different

Not different per se but not the expected UI for the OS I'm using.  I'd rather have native controls or, barring that, a native look and feel. Plus the fonts seem blocky to me.
Reply
RE: LDCad 2.0 GUI Thoughts
#10
(2017-08-23, 21:38)Orion Pobursky Wrote: Not different per se but not the expected UI for the OS I'm using.  I'd rather have native controls or, barring that, a native look and feel. Plus the fonts seem blocky to me.

The main reason for non native controls is / was the intensive use of OpenGL graphics for rendering the LDraw bricks in the part bin etc. Also I (still) have the future wish of using fullscreen OpenGL with the program.

Fonts are configurable, the default uses dejavusans or verdana on windows and freesans on Linux, you can change that though by editing gui/default/main.gu
Reply
RE: LDCad 2.0 GUI Thoughts
#4
Hi Roland,

simple question, simple answer:

* The only thing I really hate are the menus, contextual menus and how they behave, that they fly on the GUI with the need to close them (sometimes).

* https://forums.ldraw.org/thread-21693-po...l#pid23067
* I'd like to have proper icons for grid stepping (for sure the 1,2,3 keys are handy but I have no visual feedback which grid I'm using. A pressed icon would help).
* Same for the 2D/3D switch (I know the v key but sometimes I forget about it :-)
* I'd like to have a separate search icon in the parts bin near the tabs
* as much as I like the color wheel I'd like to search for a color name/number
* https://forums.ldraw.org/thread-22200-po...l#pid25807
* https://forums.ldraw.org/thread-22200-po...l#pid25788

w.
LEGO ergo sum
Reply
RE: LDCad 2.0 GUI Thoughts
#8
(2017-08-24, 8:08)Willy Tschager Wrote: The only thing I really hate are the menus, contextual menus and how they behave, that they fly on the GUI with the need to close them (sometimes).

They close when you click outside of them, the only real difference you can keep them open by pinning them down. The menu system in 20 will probably be somewhat different but the pinning feature will remain.
Reply
RE: LDCad 2.0 GUI Thoughts
#5
I agree with Owen, Orion and Willy. The difference in behaviour is the most difficult obstacle when learning to use the program.

Personally I do not like the tooltip only being visible in the status bar. It's forcing me to constantly having to refocus both my eyes and the mousepointer.

I miss the possibility to use ctrl+Y as "redo" an action.

I don't like the pop-up menu on the middle mouse button.

https://forums.ldraw.org/thread-22117-po...l#pid25219
Reply
RE: LDCad 2.0 GUI Thoughts
#9
(2017-08-24, 22:12)Magnus Forsberg Wrote: Personally I do not like the tooltip only being visible in the status bar. It's forcing me to constantly having to refocus both my eyes and the mousepointer.

I miss the possibility to use ctrl+Y as "redo" an action.

I don't like the pop-up menu on the middle mouse button.

Hint will be floating in 2.0, as I'm kinda forced to, because I'm planing to use a simpler host application library (glfw instead of wxWidgets).

You can assign ctrl+y to redo if you want.

You can also use the enter/return key for opening property dialogs.
Reply
RE: LDCad 2.0 GUI Thoughts
#6
I think the biggest reason a lot of people don't like LDCad's gui is because it doesn't look familiar at all and it looks kinda... old. A lot of desktop software often has a gui that uses either native OS elements (winforms, QT, etc.) or just looks more fleshed out (JavaFX, MS Office Ribbon interface, Autodesk ribbon interface, stud.io). Yours is neither. It doesn't use/look like native OS elements, but it doesn't look particularly well-designed either (no offense  Wink ).

Keeping a self-made gui is certainly possible. You absolutely don't need to go native, just take a look at Adobe software, Autodesk software or even Bricklink's stud.io for example; not native at all but pretty popular and people think it almost as easy to use as LDD.

I'm by far not a designer, but I think improving the looks of your gui will be the biggest improvement for most people, not necessarily its functionality. For example, yours is (currently) very flat and square. Flat is kinda a trend in modern web/app design, but in a different way. Modern design guidelines such as Google's Material Design (which I personally really like) and Microsoft's Metro use color, spacing and (slight) drop-shadows to separate ui elements, whereas you use borders (with pointy 90 degree corners) to separate the ui elements because everything is has the same blue color.

But that's just a single example. I think if you take a look at those design guidelines you might get some ideas on how to improve your ui. And I don't mean quite literally copying one of those designs (although you certainly could  Tongue ), I mean the thought behind them and why they did certain things.

But again, I'm not a designer, these are just my very personal 2 cents  Wink
Reply
RE: LDCad 2.0 GUI Thoughts
#7
(2017-08-25, 8:23)Merlijn Wissink Wrote: I think the biggest reason a lot of people don't like LDCad's gui is because it doesn't look familiar at all and it looks kinda... old. A lot of desktop software often has a gui that uses either native OS elements (winforms, QT, etc.) or just looks more fleshed out.....

Thanks for your insight Merlijn.

I'll look into those links, but I never liked metro though. The main reason LDCad's GUI is flat, is because it's easier to render.
Reply
RE: LDCad 2.0 GUI Thoughts
#11
I think Merlijn summarized well the "problem". I was never bothered by LDCad look and feel, probably because I'm an old timer and I've seen so many variants... One can wonder why Mlcad or Leocad got little criticism, that's probably because their interface, though quite outdated, is more aligned with OS standard look...
Reply
RE: LDCad 2.0 GUI Thoughts
#12
Hi Roland. Even I respect the fact you like working on your own GUI, I want to tell you my 'secret, selfish POV': I believe the situation changed during time you worked on the version 1.6. You came with many new ideas about scripting etc. that, I believe, you have completely new view on the representation of the data model and the capabilities the model should have, compared to what you started with, say, in LDCAD 1.0. (And maybe you have an idea how to allow us even something more like basics of mechanics in SR3DBuilder style?) And this is what I, as a user, am looking forward to. This is what I call a reason for 'LDCAD 2.0'.
From this POV, the own GUI (engine) is a priority 0.00001 - pop-up windows are rendered by GTK or what even today, AFAIK. So, from my, user, selfish POV, I'd like if you saved all that time of GUI work and concentrated on what you know the best, the ldraw editing. To be clear: I mean GUI engine, there is still a lot of work on the design of the application itself, of course. Some ideas are already presented in this thread and I support them: add a search box for colors etc.
I'm sorry if this is something different than what you wanted to hear Smile But I really believe the value of LDCAD is in what it 'knows to do'. And if its GUI will be more 'OS standard', we get several advantages at the same time: your time saved for working on LDCAD functionality, people not surprised by the app look&feel, GUI features you can't have time to implement them all (KDE, GTK etc. are developed for years, in big teams of people).
Reply
RE: LDCad 2.0 GUI Thoughts
#13
(2017-08-26, 5:40)Milan Vančura Wrote: I'm sorry if this is something different than what you wanted to hear Smile But I really believe the value of LDCAD is in what it 'knows to do'. And if its GUI will be more 'OS standard', we get several advantages at the same time: your time saved for working on LDCAD functionality, people not surprised by the app look&feel, GUI features you can't have time to implement them all (KDE, GTK etc. are developed for years, in big teams of people).

This is probably true, but a very big part of the LDCad hobby, for me, is doing weird things. Writing 'normal' programs is my day job Wink

This is why I even write my own string handling routines etc (hence the number/enum parsing tests in the above screen shot).

All in all I tend to view LDCad more as a game program then a office one.

The main reason for 2.0 instead of 1.7 are the internals whom were becoming messy in 1.6 because of all the unforeseen features like you suspected.
Reply
RE: LDCad 2.0 GUI Thoughts
#14
(2017-08-26, 17:28)Roland Melkert Wrote: This is probably true, but a very big part of the LDCad hobby, for me, is doing weird things. Writing 'normal' programs is my day job Wink
I know, and I respect this. I just wanted to say my opinion loudly to make it clear, to tell you how good job you do and how valuable your work about ldraw editing is for us. And, of course, I believe I'm not alone with this opinion - but somebody had to be the first one who tells you that Smile

My experience is that LDCAD is ahead of any other LDraw editor. And your work on scripting (of everything) opens doors to a completely new level of features. And, BTW, this is the kind of GUI improvement I'd appreciate: improve the GUI of selecting parts so more than one selection is possible. This allows new/planned features like triangle setting, hinge bending, hoses creation/editing using snap points of other pieces (making the hose going through selected holes or clips) and more and more, including users' scripts like, for example a regular placement of selected pieces along a selected hose etc.
This is GUI I miss, GUI in terms of 'menus' looks so boring compared to this, doesn't it? Smile
Reply
RE: LDCad 2.0 GUI Thoughts
#15
(2017-08-29, 15:42)Milan Vančura Wrote: This is GUI I miss, GUI in terms of 'menus' looks so boring compared to this, doesn't it? Smile

Fair point, but I'm also using the GUI stuff to 'practice' OpenGL shaders which I expect to influence the new brick/model rendering quality/speed.
Reply
RE: LDCad 2.0 GUI Thoughts
#16
Hi Roland,

Another suggestion I'd like to see is that the disk icon changes when a file save is successful.
Now it stays blue and I sometimes am in doubt I saved.
Once saved change it to something grey or light blue?

Thanks.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: LDCad 2.0 GUI Thoughts
#17
Hi Roland.

I know this is not about GUI only, a mix of ideas but it's the only topic for LDCad 2.0 so I put them here:

I found LDCad going extremely slow sometimes. Like updating the screen once per two seconds, nearly useless for any editing. I cannot trace real sources but it seems to be when I try to move a bigger submodel (50-100 bricks or bigger, approx.) with part snapping turned on. Also, the submodel snaps in many unwanted positions while dragged by mouse. My hypothesis is both problems are results of the same: LDCad calculates snapping for all snap objects of the moved submodel, including those "hidden" or "used" ones.
So this is my idea for LDCad 2.0: flag snap objects in the model when they are blocked and, by default, calculate snapping for "free" objects only.

Another step of this idea would be LDCad understanding the term "connected parts" - basics of mechanics in LDCad, similar to what it was in SR3D.

To end with something really about GUI only: the reason why the problem above is even worse experience is that LDCad makes the selected part "jumping" somewhere at the beginning of mouse dragging. So it doesn't help to move such submodel to a close position without snapping (no performance problems). Because when starting the next drag movement by mouse, the part (submodel) jumps. Please turn this jump function off Big Grin
Reply
RE: LDCad 2.0 GUI Thoughts
#18
(2018-02-27, 8:19)Milan Vančura Wrote: Hi Roland.

I know this is not about GUI only, a mix of ideas but it's the only topic for LDCad 2.0 so I put them here:

I found LDCad going extremely slow sometimes. Like updating the screen once per two seconds, nearly useless for any editing. I cannot trace real sources but it seems to be when I try to move a bigger submodel (50-100 bricks or bigger, approx.) with part snapping turned on. Also, the submodel snaps in many unwanted positions while dragged by mouse. My hypothesis is both problems are results of the same: LDCad calculates snapping for all snap objects of the moved submodel, including those "hidden" or "used" ones.
So this is my idea for LDCad 2.0: flag snap objects in the model when they are blocked and, by default, calculate snapping for "free" objects only.

Another step of this idea would be LDCad understanding the term "connected parts" - basics of mechanics in LDCad, similar to what it was in SR3D.

To end with something really about GUI only: the reason why the problem above is even worse experience is that LDCad makes the selected part "jumping" somewhere at the beginning of mouse dragging. So it doesn't help to move such submodel to a close position without snapping (no performance problems). Because when starting the next drag movement by mouse, the part (submodel) jumps. Please turn this jump function off Big Grin

I agree that the jumping can be a bit annoying, but I found that once I understood the reason for it, I could deal with it much better. The jump is to position the submodel/part/selection with the origin of the submodel/part/first-selected-part at the mouse cursor, so that if you're looking at the grid or the info-box to position the submodel/part/selection, then the origin goes exactly where it appears to be, rather than having some arbitrary mouse offset (which might be tough to determine precisely given you have a 2D perspective onto a 3D model).
Reply
RE: LDCad 2.0 GUI Thoughts
#19
Quote:Also, the submodel snaps in many unwanted positions while dragged by mouse.

The workaround I use when attaching a big submodel to a big model: select the part(s) where the submodel attaches, select>invert, hide. Attach submodel then unhide. Added benefit, the image is visually less busy and makes attachment easier.
Reply
RE: LDCad 2.0 GUI Thoughts
#22
(2018-02-27, 8:19)Milan Vančura Wrote: I found LDCad going extremely slow sometimes. Like updating the screen once per two seconds, nearly useless for any editing. I cannot trace real sources but it seems to be when I try to move a bigger submodel (50-100 bricks or bigger, approx.) with part snapping turned on. Also, the submodel snaps in many unwanted positions while dragged by mouse. My hypothesis is both problems are results of the same: LDCad calculates snapping for all snap objects of the moved submodel, including those "hidden" or "used" ones.
So this is my idea for LDCad 2.0: flag snap objects in the model when they are blocked and, by default, calculate snapping for "free" objects only.
This is a known limitation and the result of a less then perfect snapping engine. The system looks for matching snap info on all the dragged parts and the static ones in its 'POV' with larger models this pov is also larger so you get even more possibilities.
The official work around is to disable snapping when placing submodels (shift+p). Place them by using a logical submodel center and selecting a part in the target location before dropping.

(2018-02-27, 8:19)Milan Vančura Wrote: Another step of this idea would be LDCad understanding the term "connected parts" - basics of mechanics in LDCad, similar to what it was in SR3D.
This is something I really want but there are some problems with it making loading of models very complicated and potentially slow (has to determine all the currently occupied snapping points). But it is very high on my 'why even do a 2.0' list as it requires deep code rewrites Smile

(2018-02-27, 8:19)Milan Vančura Wrote: To end with something really about GUI only: the reason why the problem above is even worse experience is that LDCad makes the selected part "jumping" somewhere at the beginning of mouse dragging. So it doesn't help to move such submodel to a close position without snapping (no performance problems). Because when starting the next drag movement by mouse, the part (submodel) jumps. Please turn this jump function off Big Grin
Grid based moves don't have this problem. It is again a downside of the used snapping setup and also has to do with the pov of the moving selection. Once I get rendering sorted out in 2.0 I'll start thinking about the new snapping system.

(2018-02-27, 9:17)Owen Dive Wrote: I agree that the jumping can be a bit annoying, but I found that once I understood the reason for it, I could deal with it much better. The jump is to position the submodel/part/selection with the origin of the submodel/part/first-selected-part at the mouse cursor, so that if you're looking at the grid or the info-box to position the submodel/part/selection, then the origin goes exactly where it appears to be, rather than having some arbitrary mouse offset (which might be tough to determine precisely given you have a 2D perspective onto a 3D model).
This is indeed the problem in a nutshell.

(2018-02-27, 17:50)Milan Vančura Wrote: One request more: usually I know (in advance) where I want to place new part. It's unnecessary to fly with the new part at cursor, over all the model, letting all parts of the model "pull" the new part to their snap points. Especially when it's sometimes hard to point to the final place (try to put 40t gear on axle).
That is a possible solution. Also the current snapping stuff isn't multi threaded the one in 2.0 will be so that should allow for some more breathing space too.

In 1.6 You can also disable snapping while moving the selection around and enable it again when you roughly at the place you want to be (shift+p)



(2018-02-27, 17:50)Milan Vančura Wrote: It would be great to ave an alternative: mark the destination part on the model in advance so the new part will snap to this part ONLY - just cycle trough its snap points. Or even better, select the specific snap point in advance. More clever heuristics would even filter snap points of the new part so only those matching the selected one are active...
40t gear can be fun indeed the main trick is the angle you look upon the model. Early version of the engine was even more fun as the axle didn't 'stick' to a current hole making it jump holes all the time Smile


(2018-02-27, 17:50)Milan Vančura Wrote: And as I cannot absolutely estimate when we will see LDCad 2.0 (in a year? or more? it's a complex piece of SW...) it really a worth to have such workaround!
Work ion it s a bit slow currently as I'm behind on my real life work and have little time for LDCad (hence the delay in 1.6b).

Time should clear up in a couple of weeks though

Thanks for the input all
Reply
RE: LDCad 2.0 GUI Thoughts
#20
Thank you both for your tips and explanation, Owen and Philippe.
I understand the technical reason for that jump but I'm not a machine Smile This is often a case in LDCad GUI: it tends to be too technical. This case about surprising jump is a perfect example, this is why I request LDCad being more intuitive here.

About placing big submodels: big thanks for the tip, Philippe! It looks like a useful workaround for now. And as I cannot absolutely estimate when we will see LDCad 2.0 (in a year? or more? it's a complex piece of SW...) it really a worth to have such workaround!

One request more: usually I know (in advance) where I want to place new part. It's unnecessary to fly with the new part at cursor, over all the model, letting all parts of the model "pull" the new part to their snap points. Especially when it's sometimes hard to point to the final place (try to put 40t gear on axle). It would be great to ave an alternative: mark the destination part on the model in advance so the new part will snap to this part ONLY - just cycle trough its snap points. Or even better, select the specific snap point in advance. More clever heuristics would even filter snap points of the new part so only those matching the selected one are active...

More generic: to be able to mark both snap points which I want to join (one on each part) and press "join".
Reply
RE: LDCad 2.0 GUI Thoughts
#21
Quote:try to put 40t gear on axle

Another workaround Wink
Place a 8t instead, then while it is selected, double click on 40t gear in the bin... Done! Very useful too for a part that doesn't have connectivity yet but is similar to another one...
Reply
RE: LDCad 2.0 GUI Thoughts
#23
I think the LeoCAD GUI is very slick, though it is still a ways farther behind LDCad in terms of offering features. Once it catches up, I will probably be using it exclusively.
Reply
RE: LDCad 2.0 GUI Thoughts
#24
(2018-02-28, 1:58)Michael Horvath Wrote: I think the LeoCAD GUI is very slick, though it is still a ways farther behind LDCad in terms of offering features. Once it catches up, I will probably be using it exclusively.

It has nice button icons but other then that it's basically mlcad imho.

The big problem I'm having is not being an artist so I'll automatically end up with very flat simple looking icons.

The LDCad 2 gui will be heavily depended on "Skin" images so in theory it could be just as slick if someone makes nicer images for it.
Reply
RE: LDCad 2.0 GUI Thoughts
#25
(2018-02-28, 19:06)Roland Melkert Wrote:
(2018-02-28, 1:58)Michael Horvath Wrote: I think the LeoCAD GUI is very slick, though it is still a ways farther behind LDCad in terms of offering features. Once it catches up, I will probably be using it exclusively.

It has nice button icons but other then that it's basically mlcad imho.

The big problem I'm having is not being an artist so I'll automatically end up with very flat simple looking icons.

The LDCad 2 gui will be heavily depended on "Skin" images so in theory it could be just as slick if someone makes nicer images for it.

I believe the icons that LeoCAD uses are standard Windows icons that can be found in various DLL files in %systemroot%\system32\
Found at: https://www.digitalcitizen.life/where-fi...tive-icons
but this goes for all versions of Windows, I think.

Once LDCad 2 is out, I am more than willing to create icons and share them.
Most icons for standard actions like open, save, close, etc. can be easily used from standard Windows programs and be made as images the can be used.

For what the GUI of LDCad is now I am happy with it, like it is. But I can imagine some people will find it most confusing.
Though I must say LDCad is not aimed at your average Windows / LDraw user. I am wondering how many people who start with LDraw will and can understand working with it.
It took me a couple of months to get used to and since I was a die-hard MLCad user this took a lot of effort. I even gave up trying to learn and understand it at some point.
Now that I am comfortable with LDCad, I am very happy to learn and use it all the time as my basic LDraw editor, though I sometimes refer to MLCad, like mentioned.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: LDCad 2.0 GUI Thoughts
#26
(2018-03-05, 11:44)Jaco van der Molen Wrote: I believe the icons that LeoCAD uses are standard Windows icons that can be found in various DLL files in %systemroot%\system32\

They are custom icons made by a user.
Reply
RE: LDCad 2.0 GUI Thoughts
#27
(2018-03-09, 2:31)Leonardo Zide Wrote:
(2018-03-05, 11:44)Jaco van der Molen Wrote: I believe the icons that LeoCAD uses are standard Windows icons that can be found in various DLL files in %systemroot%\system32\

They are custom icons made by a user.

Oh, OK. They look pretty standard though ;-)

Anyway, I think I can make icons for LDCad if there's a need.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: LDCad 2.0 GUI Thoughts
#28
(2018-03-09, 6:28)Jaco van der Molen Wrote: Anyway, I think I can make icons for LDCad if there's a need.

I've been playing with GIMP myself but it doesn't look promising to say the least, so any help would be very much appreciated Smile
Reply
RE: LDCad 2.0 GUI Thoughts
#29
(2018-03-09, 18:56)Roland Melkert Wrote:
(2018-03-09, 6:28)Jaco van der Molen Wrote: Anyway, I think I can make icons for LDCad if there's a need.

I've been playing with GIMP myself but it doesn't look promising to say the least, so any help would be very much appreciated Smile

OK, I can give this some thought and try. What format (PNG?) and size should the icons be?
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: LDCad 2.0 GUI Thoughts
#30
(2018-03-10, 10:49)Jaco van der Molen Wrote:
(2018-03-09, 18:56)Roland Melkert Wrote: I've been playing with GIMP myself but it doesn't look promising to say the least, so any help would be very much appreciated Smile

OK, I can give this some thought and try. What format (PNG?) and size should the icons be?

I will only support png (rgba), not sure on the icon sizes yet.

I've been working on basic skin 'wallpapers' only as they are used to draw the part bin etc.

Things can also change in a blink as it is all still very experimental. Once I've got it to a point I will need 'serious' images I'll probably start a new topic on the forum.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)
Forum Jump:


Users browsing this thread: 1 Guest(s)