GitHub and My computer problems

[mik_s]

In addition I would be slightly worried of minuscule "tin bridges" that could lead to short circuits that could kill your motherboard. I mean, when you heat up the stick, I would guess that the solder of the neighboring chips would also liquefy, and that it would be very easy to make a short somewhere that isn't easily detectable. Without a tester, you'd have to use your motherboard as the "tester", which could become much more expensive. But, if you're willing to risk this and the time and effort required, go for it I'll be rooting for you!

It's actually not an issue if you use plenty of flux. Solder has a high surface tension and will only want to stick to bare metal. PCB's have a solder mask so the solder will only go where it's meant to. when soldering with hot air you can actually see the component move into the perfect position once the solder is melted, it doesn't need to be perfectly aligned. Any shorts wouldn't cause damage to the motherboard either, it would detect there is something wrong and refuse to POST. This is how to do it correctly, and this is how not to do it

GUI things are quite hard to do in Java (there is a reason our GUI sucks!)

So that explains that I'm up for the challenge of giving it a try though. I'll have a look for examples, copy and modify their code then build from there. If I do manage to get a GUI made I'll need someone to do the code that goes behind it that actually does the work, like taking the values from it and creating the conf.

[Nadahar]

It's actually not an issue if you use plenty of flux. Solder has a high surface tension and will only want to stick to bare metal. PCB's have a solder mask so the solder will only go where it's meant to. when soldering with hot air you can actually see the component move into the perfect position once the solder is melted, it doesn't need to be perfectly aligned. Any shorts wouldn't cause damage to the motherboard either, it would detect there is something wrong and refuse to POST. This is how to do it correctly, and this is how not to do it

You are braver than I am, so much confidence that everything works out Kudos to the guy that did it with a hand-held heat gun - I don't think I'll ever attempt that on board I care about I know the surface tension stuff, I just don't "trust" it. For everything to work out, you must have "good" flux, the right temperatures and generally know what you're doing. I have a troubled relationship with flux... especially with cleaning it up afterwards.

As to the pyro guy.... ROFL! If it worked I guess a congratulation should be in order, but when speaking of "controlled temperatures" - this must be the exact opposite. It was funny, but I don't think I would have trusted that stick for anything....

[mik_s]

I had to cave and buy a new stick, things are running too slowly to do anything much atm

Been looking into the GUI and the different types. I had a play around with the Eclipse WindowBuilder and it is fairly comprehensive and takes out a lot of the setting up of the code. It's pretty much drag and drop, changing a values in each elements properties and the code is auto generated. It is also getting updated too as there was one the other day.

I did try opening various elements of the UMS GUI with varying degrees of failure
I was thinking of trying to redo the GUI in WindowBuilder, and keep all the auto generated code to draw the GUI separate from human written code to handle the elements. been watching some tutorials on it and that seems like common practice. This would also be easier for me as I don't have to learn a lot of code to do it.

So the next question is if I'm rewriting the GUI, what framework to use?
I understand that AWT is the lowest common denominator, will only support the native features of the worst platform so it will work on all.
Swing is done by java and is kind of emulated to give the look and feel of different platforms, but as nothing is native then is less responsive
SWT has native support and more features but each platform needs its own SWT module specific to it.

Eclipse seems to make SWT easy once set up (yes it was a bitch when you don't know what you are doing ) as for setting up for different platforms and maintenance I guess that is something maven can handle? (not really sure what maven does exactly but I assume it will handle dependencies)

I guess SWT makes more sense even it it means a little extra work to compile.

[Nadahar]

Using SWT would make UMS drastically more labor-intensive to maintain. I don't think it would be worth it, although there's no doubt that it gives the superior result.

AWT isn't really an option, it does pretty much nothing useful. Swing has also been abandoned and is full of issues, but it's kind of the best choice anyway, unless one wants to gamble on rewriting everything for JavaFX - and hope that it will stay around long enough to make it worth the effort.

But, I think you're missing one very essential thing. The "work" in making a GUI is making it work - the coding, that you think you can get somebody else to do. Using WindowBuilder or a similar tool is fine when you build something from scratch, but all it does is give you "an empty shell" that doesn't actually do anything. 90% of the work still has to be done using code, so it's not the "revolutionary" thing it might seem. Everything in UMS' GUI has to actually do stuff in addition to appearing on the screen, and that's where most of the work is. Learning to change the layout of the components using code isn't that hard, except when you get too deep into the layout managers.

Another challenge is to make things actually work on all platforms. Swing, although supposedly platform-agnostic, has many platform specific bugs. So, even though what you just made looks OK on your screen, it might not be so good on another OS. In addition, UMS' GUI has multi-language support, which is quite a challenge layout-wise. Strings that are short in one language might be very long in another, so you can make no assumption as to the length of texts. It should also work across resolutions, with different fonts etc. The frosting on the cake is that it should also support RTL, although UMS currently fails quite miserably on that some places as it is.

What I'm trying to say is that actually deciding which components to put where is a very, very little part of making a GUI. There's a reason why "everybody" hates making GUIs

[mik_s]

I do understand that there is a lot more than just the shell and I am learning more about how that all works.
The way I was thinking of doing it is take one section at a time and transplanting the original code across and make any changes to make it work.
I'm no good at writing code from scratch, but I can usually modify someone else's to do what I want. For something new I will probably need help.
Once I have a working copy of the original GUI then I'll see what improvements can be made.

No idea how translation is done in UMS but I'm sure I'll get an idea once I start. Not sure but I think there may be support in WindowBuilder to help design around that, something I'll need to look into. Maybe you'll get the frosting too

What do you mean exactly about maintenance? I know that each platform will need it's specific part when compiling, but can that done automatically in the build options? or is it more than that?

[Nadahar]

The translation itself is already handled, it's as simple as instead of writing strings with text in the code, you create a "label" in the "main translation file" and simply refers to that label from the code. The translation files are then translated by translators using Crowdin and imported back into UMS.

The challenge is rather to make something behave dynamically enough to work under all these different circumstances, and still look reasonable and be "user friendly". I guess you have to experience it to really understand, I can just tell you from experience that you can make something work just as you imagined, just to discover when trying it under different circumstances that it fails miserable there.

With "maintenance" I mean all the extra work that goes into developing and maintaining under those circumstances. I don't know all the details of how SWT works, but you would for example in some way or another have to develop everything GUI related on all supported platforms. Since it utilize the native GUI elements, you don't have the same options on the different platforms, so you would have to adapt the GUI to each platform. In addition I'm sure it would complicate many processes like automated testing and building. Just imagine how hard it would be to make any changes when the developer in question would need access to all the different platforms when developing.

[mik_s]

From what I have seen so far, anything that is not supported on a particular platform is handled by the SWT framework while passing the rest to be done natively. So in theory you wouldn't need to worry about building the GUI for each system, just the one and SWT handles the rest. Probably out of date (10 years) but i think this explains things better.

The challenge is rather to make something behave dynamically enough to work under all these different circumstances, and still look reasonable and be "user friendly". I guess you have to experience it to really understand, I can just tell you from experience that you can make something work just as you imagined, just to discover when trying it under different circumstances that it fails miserable there.

I'm with you there. When I was helping a friend to write a website years ago, It looked good on my screen using firefox, but was unusable on chrome with a different resolution. There were some tricks to scale things correctly on different browsers which fixed it in the end.

[Nadahar]

Regarding SWT, one thing is to claim that "the framework will bridge the gap", another thing is how this works in practice. I don't know, but I am skeptical of this working "good enough" that you don't need to test all changes on all platforms.

That said, I think SWT does many things right, but it has a somewhat bad reputation for being "difficult" to work with. All I know is that I did try to give SWT a real good look some years ago, and I concluded that it was too much of a hassle to make it a viable alternative to Swing. Sadly, I don't remember the details of my "evaluation", only my conclusion. It might be wrong, but for now I'll stick with my previous conclusion despite not remembering the details leading up to said conclusion

[mik_s]

I'll give it a go with SWT and then we'll see how things turn out. I'll probably completely fail but at least I will be able to understand how things work in UMS better . Maybe you will change you mind

Next question is, where is the start of the GUI code? Can see all the classes used for each tab but can't see the one that creates the main window.

[Nadahar]

The GUI classes are in the "newgui" package. "LooksFrame" is the one spawning all the others.