Announcement

Collapse
No announcement yet.

GXUI: A New Cross-Platform UI Library By Google

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Luke_Wolf
    replied
    Originally posted by SystemCrasher View Post
    There is one fancy thing though: REAL cross platform solutions do not require all this weird crap. You see, GTK based program runs anywhere as a matter of recompile. Qt does it even better and on even more plaftorms, with even more native look. Even SDL based game would do so. Java would do it as well (though crappy, but at least it works). So it usually takes Z-E-R-O changes to code. And whole need to change code completely screws up "write once, run everywhere" idea. Far harder than need to recompile source. Recompiling does not takes much effort and could be automated. Writing some extra code is not and it really creates dumbass problem out of nowhere. Only really insane devs would turn MS greed and their overall inability to think beyond Winduz into their own problems.
    So... using MVC as a design pattern for GUI applications is "weird crap" now, got it. Reality is there's two schools of thought when it comes to going cross platform, the first is that of writing the application including the interface one time for all platforms, this saves developer time with the result being an application that is tightly bonded to the GUI toolkit, this can work well in situations where the toolkit performs theme integration, but otherwise the application will look awful and out of place on every system (see most Java GUI applications). If we want to bring in games then that really isn't so much a problem, however if you want to write games in C# SDL is available through OpenTK, and MonoGame is an open implementation of XNA.

    The other alternative is realizing that the GUI is in most cases a rather small part of an application and as a result that if the application is designed properly then the actual application logic effectively exists as a library that is then used by your GTK, Qt, Console, etc frontends. With it being quick and easy to bring up a new one. This has the advantage in that you're enforcing loose coupling, and your application is going to be specially integrated with the environment that it is targeting.

    Originally posted by SystemCrasher View Post
    There is only couple of probs:
    1) It is not a native part of .NET, and so it would give extra headache to devs who will have to learn a lot of technical cruft about dotnet internals and how to plug their UI lib to .NET and how to supply it to user in usable way. If one thinks devs are in mood to have it as hard as that - good luck with it!
    Apparently plenty of people are doing just that otherwise Xamarin wouldn't exist as that is their entire business, GTK# wouldn't exist, and QtSharp wouldn't be being developed, OpenTK wouldn't be a thing, and on and on and on. But all that aside that has absolutely no impact whatsoever on the end developer who just takes a set of DLLs, likely that they didn't even have to manually install as opposed to getting off of nuget, and make sure it gets deployed with the application.

    Originally posted by SystemCrasher View Post
    2) Somehow you're silly enough to assume devs can have uber-goal to use .NET at all costs. This is fucking wrong idea from MS zealots.
    It's silly to assume that people want to use one of the most popular languages/platforms? What planet do you live on?

    Originally posted by SystemCrasher View Post
    And from my experience, if one is real about about being cross-platform, first step is to completely forget about MS and their techs. They proven to be really hostile to cross-platform things, because they're inherently interested in vendor lock.


    Fortunately most devs are not insane enough to face all this "native" support from MS. All this "cross"platform support is so formal and third-rate they better to shut up with their marketing bullshit. It really suxx when marketing advertisements are better than actual software and it is what I hate about MS products.
    And well... this is simple blind zealotry...

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by DanLamb View Post
    - Almost no one is doing desktop client GUI applications any more. That has become an extreme niche field. Web browsers, chat clients, terminal apps, IDEs, content creation apps with sound+graphics, and games... That's mostly it.
    If nobody is doing desktop client gui applications any more then nobody was ever making them in the first place. The only real difference is that no cost alternatives have displaced commercial software in most sectors, otherwise the desktop GUI field is alive and well. Reports of the death of the desktop are, as always, greatly exaggerated.

    Leave a comment:


  • DanLamb
    replied
    Originally posted by caligula View Post
    Also Java IDEs can be slow (GUI wise).
    - Java IDEs are slow because of all the stuff they are doing. They are mega applications. Visual Studio is often slow as well.
    - Java GUI apps are pretty zippy and responsive. JavaFX is a nice choice.
    - Almost no one is doing desktop client GUI applications any more. That has become an extreme niche field. Web browsers, chat clients, terminal apps, IDEs, content creation apps with sound+graphics, and games... That's mostly it.

    Leave a comment:


  • SystemCrasher
    replied
    Originally posted by caligula View Post
    To be honest my Haswell computer is already slowing down if I run 8 flash video applets at the same time. I don't know why since it can decode those videos at over 8x realtime easily. I also experience lag in KDE applications and the browsers seems a bit slow. Also Java IDEs can be slow (GUI wise). So I don't know. I'm using XFCE and quite happy with it. But still, the same desktop works happily even on a 10 year old PC.
    But you see, XFCE is not going for super-duper-plasmoids, mega-SQL-databases in separate processes to store all contacts and email (for couple of shitty apps on the whole planet) and so on. So XFCE works fine on 10 years old desktop. OTOH KDE suxx quite a lot on such hardware. And Java? Oh, you'll swear way too much using Java programs on 10 year old PCs.

    Leave a comment:


  • SystemCrasher
    replied
    Originally posted by Luke_Wolf View Post
    If your GUI application is properly written (and not something like a CAD program that does significant computation in the UI) then the actual GUI code itself is minimal, and in fact you can pretty easily throw out a WPF, WinForms and GTK# frontend for it.
    There is one fancy thing though: REAL cross platform solutions do not require all this weird crap. You see, GTK based program runs anywhere as a matter of recompile. Qt does it even better and on even more plaftorms, with even more native look. Even SDL based game would do so. Java would do it as well (though crappy, but at least it works). So it usually takes Z-E-R-O changes to code. And whole need to change code completely screws up "write once, run everywhere" idea. Far harder than need to recompile source. Recompiling does not takes much effort and could be automated. Writing some extra code is not and it really creates dumbass problem out of nowhere. Only really insane devs would turn MS greed and their overall inability to think beyond Winduz into their own problems.

    That said QtSharp is being developed https://github.com/ddobrev/QtSharp so that problem will solve itself within a short time.
    There is only couple of probs:
    1) It is not a native part of .NET, and so it would give extra headache to devs who will have to learn a lot of technical cruft about dotnet internals and how to plug their UI lib to .NET and how to supply it to user in usable way. If one thinks devs are in mood to have it as hard as that - good luck with it!
    2) Somehow you're silly enough to assume devs can have uber-goal to use .NET at all costs. This is fucking wrong idea from MS zealots.

    And from my experience, if one is real about about being cross-platform, first step is to completely forget about MS and their techs. They proven to be really hostile to cross-platform things, because they're inherently interested in vendor lock.

    Also GTK# IS in fact supported by native .NET hence why Monodevelop (on windows known as Xamarin Studio) can be run on the native .NET stack, and Mono usually isn't installed with it.
    Fortunately most devs are not insane enough to face all this "native" support from MS. All this "cross"platform support is so formal and third-rate they better to shut up with their marketing bullshit. It really suxx when marketing advertisements are better than actual software and it is what I hate about MS products.

    Leave a comment:


  • cb88
    replied
    Originally posted by bnolsen View Post
    I wrote a layout engine for fltk2 to remove any use of hard coded sizes and coordonates a while back (fltkl i think). I've been meaning to port/fork fltk2 over to use sdl2 as the backend, just need money and time (as usual).

    gtk isn't so great cross platform and qt is definitely bloated. has serious problems with non orthogonality and definitely has plenty of surprises if you try to dig into it.

    it's been a while since I tested but a few years back qt4 took 40 mins to compile. fltk2 compiles in 8 seconds flat on my dev machine, libraries, utilities, test programs and all.

    gxgui will take some reading to see if they have any cool new enlightened ways of doing that boring gui thing no one ever seems to get right.
    FLTK 2 is dead... completely don't every never use it

    Instead use FLTK 1.3 and possibly in the future 3.x. But 1.3 is where it is at these days.

    Leave a comment:


  • sloth77
    replied
    Originally posted by caligula View Post
    Hard drives used to transfer max 5 MB/s when I was a kid.....
    You lucky sod! When I was a kid, we had cassette drives that transferred 50 bytes per second!

    (http://en.wikipedia.org/wiki/Commodore_Datasette)

    Leave a comment:


  • caligula
    replied
    Originally posted by rdnetto View Post
    Not at all. I used 'low-level' in the sense of a high-level language, since Qt actually uses macros to embed a list of null-terminated strings and integers in QObjects to represent the type info, in such a way that connecting signals and slots at runtime is O(1). That they do this in such a way as to be transparent to the programmer contradicts your argument that one needs to micro-optimize. (In fact, one could make the argument that Qt is actually quite good at putting that GPU to work by using OpenGL, though I won't as I'm not particularly familiar with it.)

    Now, those techniques are certainly not going to be low-level compared to what was going on in the 80s, but it is true that an obvious/naive implementation (which would likely be O(n)) could result in significantly longer start-up times that the user would notice. For example, WPF .xaml files worked basically the same way that Qt's .ui files did, but when I tried using them in .NET 4.0, even a simple application took over a second to load.

    You don't need to micro-optimize, but you absolutely do need to make some sane decisions about your design and algorithms if you care about performance.
    Even if you use the worst possible algorithms, the GUI will work just fine today. The main reason is that computers are around 10^6 to 10^8 times faster than the first computers that had a multicolor mouse driven GUI and the graphical needs are only 25 times as big as in the 1980s. The next big reason is that even with a slow CPU and a very shitty language for high performance code (e.g. Python), you can still achieve good GUI performance on hardware like Raspberry Pi. The GPU is very powerful. The Raspberry is about as fast as Pentium 2 and people use it to run interpreted languages. Still it can easily display 1920x1080 truecolor graphics. The Raspberry Pi is about as fast as 486DX when you run non-jitted Python/Javascript on it. Still, it runs 1920x1080x24b @ 30 fps easily.

    Leave a comment:


  • caligula
    replied
    Originally posted by SystemCrasher View Post
    That's why some clueless devs should be forced to test how their programs perform on 10 years old PCs. Otherwise users are swearing here and there when some idiot tested his program on super-duper configuration which exceeds 95% of computers and then surprised like a hell to read negative feedback from users who are not happy with how this horrible shit performs on THEIR systems. I'm sorry to inform you, but many users are really unhappy about idea to buy $1000 GPU and they also will have certain technical difficulties doing so on some notebook. Not to mention that even if some notebook comes with 4 cores, attempt to use all 4 cores at maximum speed would literally kill battery. But who cares? Sure, these losers can grab some generator to extend battery time, yeah?
    To be honest my Haswell computer is already slowing down if I run 8 flash video applets at the same time. I don't know why since it can decode those videos at over 8x realtime easily. I also experience lag in KDE applications and the browsers seems a bit slow. Also Java IDEs can be slow (GUI wise). So I don't know. I'm using XFCE and quite happy with it. But still, the same desktop works happily even on a 10 year old PC.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by Togga View Post
    Then why use it at all? It just brings ju tons of baggage to bring along that's a pain for portability whatever new, interesting HW platform you want to run it on. Complete madness.
    Yeah! Why don't we all just write out all our problems in Machine Code? Performance is Everything for Every Program!.... Oh Wait.... no, no it's not. People choose to write in C# as opposed to C or C++ because they value safety and developer time over the raw performance of the binary (However it's worth noting that sometimes C# implementations of a concept are faster than C or C++ implementations of a concept, as seen here http://codicesoftware.blogspot.com/2...mark-test.html for example). Which is in all reality the right move because for most applications the performance difference is invisible, while an increase in developer productivity and safety is very visible. As it means less bugs and whole categories of security issues disappear.

    Let's step back for a moment though and consider applications we run, what does "fast" really mean? Is it how fast a music player can process a song? Is it how fast the cursor blinks in our document editor? is it how quickly the loading bar displays it's animations? No... the "speed" of an application is generally speaking two things: Startup Time, and how quickly it performs the task we set it to do. For the latter what we really mean most of the time is "How responsive is an application?". Which effectively means will the program react as expected to user input within ~250ms (The time it takes for a human to react to something as per http://www.humanbenchmark.com/tests/...ime/statistics) if it wants to be perceived as instantaneous. This is actually a really long time for a computer: 750,000,000 cycles to be exact assuming a 3Ghz computer, as a result even languages that are actually slow (unlike C#) can handle this, as what most applications users use are not CPU bound in any way, but user input or disk bound.

    Further C# is apparently fast enough for game development given that it's the exclusive platform for the PS Vita. The Playstation, Wii, and XBox all have it available as an actively used option, and Unreal considers it fast enough to supersede UnrealScript for scripting games. Once again as well Dust: An Elysian Tail, which is a C# and XNA game is certainly not slow, in fact it's been praised by well respected individuals such as TotalBiscuit for its extremely responsive combat system. If it's fast enough for games then it's fast enough for most applications, and with the advent of .NET Native allowing for the same kind of deep optimizations that C or C++ get... well.. we'll see how things look in the future.

    On a further note, I fail to understand what you're talking about in regards to pain for portability, pure .NET code is in fact more portable than C or C++ because it's compiled into IL as opposed to a machine specific format, thus meaning that the only requirement is that you do whatever porting is necessary to make the CLR run on the target platform and then all your .NET code works just as it does on other platforms. Same goes for Java or Scripting languages and is one of the usual touted "strengths" of those platforms. Now if you depend on platform specific libraries then yes of course you're going to have problems, but that is a language independent problem.

    Leave a comment:

Working...
X