Emerald Editor Discussion
September 20, 2017, 10:58:20 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: 1 [2]
  Print  
Author Topic: Opportunity to rethink the programming language and GUI library  (Read 20311 times)
0 Members and 1 Guest are viewing this topic.
Pvt_Ryan
Master Jeweller
******
Posts: 422



WWW
« Reply #15 on: May 20, 2007, 08:49:16 pm »

I support C/C++ options. I would prefer rather GTK+ than wxWidget, exactly because it DOESN'T have native look and feel. It has the same look and feel on every platform.
This is, in example, the reason why Firefox (GTK+) looks cool on anything just the same.

True, but you'll note that Firefox has recently reported that version 3.0 is going to have the Mac look and feel on Macs because they were getting so many complaints about it.

Maybe, but imo that's just a theme issue. Since we will have separate binaries for windows, nix and mac then we just set a different "default" theme in the binary, problem solved.
Logged
jonnymind
Miner
**
Posts: 18


« Reply #16 on: May 20, 2007, 09:32:49 pm »

FFx is GTK?

I suppose you meant Firefox.

Hello. Welcome to the world.

Actually, Firefox/mozilla even exposes an embeddable GTk+ widget that actually works as "firefox-in-a-box" for GTK+ apps.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #17 on: May 20, 2007, 11:40:07 pm »

Just to clarify: Firefox does not use GTK; it uses its own XUL rendering engine, which is definitely not GTK-like. There are plans about for a GTK port, though.

From my opinion, let's look back at CE. CE is unobtrusive and uses a basic interface with a custom editing widget. It has standard icons, standard-looking toolbars, standard-looking menus, but the focus is the editing widget, and that is where we must concentrate.

I liked originally, and still do like, the concept of a cross-compiling application which looks mostly/completely native on every platform. The idea of EE was to seamlessly integrate under the hood in each environment. But that's me.

I like the fact that Firefox does actually, despite not using standard GUI components, look relatively integrated. It takes on the same colour scheme that the rest of my apps do, and doesn't go out of its way to draw attention to itself, which is how I think any down-to-earth app must be.

I feel that with a text editor especially, it should be down to earth, not draw too much attention to itself and just do its thing. EE is not meant to be an IDE. That means it isn't trying to be a complete environment in itself. With the plugins discussed, it could potentially become that, but it isn't designed that way as intended. I don't think it can have the luxury of being enough of an IDE to wave its arms in the air and say "Hey, look at me, I'm pretty!"

I'm not saying it has to be native, but native-like, hence my direction of wxWidgets. The change in API is, however, something of an issue, as is wxWidgets' habit of building multi-megabyte builds when not linking libraries.

Having gone over it all, I'm contemplating us taking the view of having a platform agnostic GUI interface, which is turned into a platform specific one at build stage - like Firefox does. That would also help with the plugin system since you'd be able to hook into the menus, build dialogues etc.
Logged

"Cleverly disguised as a responsible adult!"
John Yeung
Senior Miner
***
Posts: 85


« Reply #18 on: May 21, 2007, 03:18:12 am »

One of the main goals of EE is to be a fast performer, particularly during startup.  How fast??  On Windows it should be a suitable replacement for Notepad.  At the moment, CE accomplishes that no problem.

Unlike rageboy, my experience with Crimson is that it has never been anywhere near as fast as Notepad.  I always marvel at the people who claim Crimson is fast and light on memory requirements.  In my opinion, it is merely "fast enough" and it uses memory fairly inefficiently.  This may have a lot to do with the abilities and configuration of the computers I use, the way I like to work, etc.  But I am pretty sure Crimson either doesn't allocate memory that intelligently with many and/or large documents open, or has some kind of memory leak.  Very possibly both.  (And there definitely were some complaints in the past on Crimson's forum that it was a memory hog in some situations.)

I don't think there is any shame in any of this.  It does a hell of a lot more than Notepad and is necessarily vastly larger than Notepad.  It is also reasonably competitive in performance and memory with a fair number of other software packages.  (I am extremely surprised when any Windows program doesn't use more and more memory as uptime increases.)  But if there is a performance "bogey" for Emerald, let it be SciTE, not Crimson.

John
Logged
Szandor
Senior Miner
***
Posts: 92



« Reply #19 on: May 21, 2007, 11:16:53 am »

One of the main goals of EE is to be a fast performer, particularly during startup.  How fast??  On Windows it should be a suitable replacement for Notepad.  At the moment, CE accomplishes that no problem.

Unlike rageboy, my experience with Crimson is that it has never been anywhere near as fast as Notepad.

I definitly agree here, although I have to say that in my mind, EE will outperform CE by a lot when only basic editing features are enabled. This is why we need the plugin system, to make it possible for people to start the program with no extras enabled, making EE perform lightning fast. I never use the project features in CE - why should it be there and slow down my app then? More power - less bulk! (With bulk being optional, should people want it.)

I also agree that a native feeling is critical to make the program successful. Should we ever want a special interface for it  we should let that be handled by a plugin. This is also another great opportunity to suggest that we use the great looking silk icons by Mark James. Free for use under the Creative Commons Attribution 2.5 License.
Logged

"Cleverly disguised as an original signature..."
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #20 on: May 21, 2007, 03:00:44 pm »

is purdy Grin
Logged
Phil
Administrator
Master Jeweller
*****
Posts: 427


« Reply #21 on: May 22, 2007, 04:07:32 am »

I don't want to change topics in the thread, but the silk icon set is 16x16 PNGs. I would strongly prefer larger icons so I don't have to squint to distinguish them.

Phil
Logged
Phil
Administrator
Master Jeweller
*****
Posts: 427


« Reply #22 on: May 22, 2007, 04:10:31 am »

Also, about native look and feel. I personally feel like it is good to use the native APIs for control rendering (as wxWidgets does) because what if the user has a custom look installed or made their own look and feel. Even if we styled a GTK+ app to look like Windows XP or whatever, the program would then look like Windows XP instead of their custom style.

Phil
Logged
jonnymind
Miner
**
Posts: 18


« Reply #23 on: May 22, 2007, 09:41:08 am »

Just to clarify: Firefox does not use GTK; it uses its own XUL rendering engine, which is definitely not GTK-like. There are plans about for a GTK port, though.

I apologize; Mozilla/Firefox has its own widget library that directly render the widgets in the target platform native API (i.e. windows GDI).

However...

gian@2[~]$ ldd /usr/lib/firefox/firefox-bin
        linux-gate.so.1 =>  (0xffffe000)
        libmozjs.so => not found
        libxpcom.so => not found
        libxpcom_core.so => not found
        libplds4.so => /usr/lib/libplds4.so (0xb7f8e000)
        libplc4.so => /usr/lib/libplc4.so (0xb7f89000)
        libnspr4.so => /usr/lib/libnspr4.so (0xb7f59000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7f48000)
        libdl.so.2 => /lib/tls/libdl.so.2 (0xb7f44000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7c6f000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7bf2000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7bd9000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7bc4000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7bbc000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7b8d000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7b80000)

So "port plans" are quite fulfilled ;-)

Also, the GTKMozEmbed widget works on windows (I used it. That was the source of my mis-recalls ;-)

And XUL is not a widget engine, but just an XML extension that is interpreted by the Mozilla widget engine, and that can be used by extensions in any language (i.e. Javascript) to open windows, show buttons etc...

Gian.

Logged
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #24 on: May 22, 2007, 02:08:35 pm »

I don't think Mozilla's library is the only one that does this (AWT?). Would it be possible for us to pick something similar?
Logged
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #25 on: May 22, 2007, 02:10:50 pm »

I don't want to change topics in the thread, but the silk icon set is 16x16 PNGs. I would strongly prefer larger icons so I don't have to squint to distinguish them.

Phil

I thought he said he could give us larger versions? Though I agree with you, 16x16 is a tad small.
Logged
Szandor
Senior Miner
***
Posts: 92



« Reply #26 on: May 22, 2007, 03:27:36 pm »

I don't want to change topics in the thread, but the silk icon set is 16x16 PNGs. I would strongly prefer larger icons so I don't have to squint to distinguish them.

Phil

I thought he said he could give us larger versions? Though I agree with you, 16x16 is a tad small.
You're all blind as bats! Clever bats with digits long enough to operate a computer, granted, but still!

That aside, making them bigger isn't a problem. The silk library is completely free to use in any way we want, including making larger versions.
Logged

"Cleverly disguised as an original signature..."
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #27 on: May 22, 2007, 03:44:29 pm »

You're all blind as bats! Clever bats with digits long enough to operate a computer, granted, but still!
lol
Quote
That aside, making them bigger isn't a problem. The silk library is completely free to use in any way we want, including making larger versions.

but anytime you increase an image (by zooming anyway) resolution gets screwy. I guess we could make them larger ourselves, but I'm not taking on that task. I don't want to figure out how to enlarge something without needing to redraw it. If everyone knows how and I'm just an idiot then I'm sorry Tongue Be nice to know how though if you could tell me Wink
Logged
Szandor
Senior Miner
***
Posts: 92



« Reply #28 on: May 22, 2007, 05:08:32 pm »

Quote
That aside, making them bigger isn't a problem. The silk library is completely free to use in any way we want, including making larger versions.

but anytime you increase an image (by zooming anyway) resolution gets screwy. I guess we could make them larger ourselves, but I'm not taking on that task. I don't want to figure out how to enlarge something without needing to redraw it. If everyone knows how and I'm just an idiot then I'm sorry Tongue Be nice to know how though if you could tell me Wink

There are actually several ways to go, some better than others. Just resizing it will make it look all pixled while using different algorithms will improve quality in different ways, depending on what algorithm you use.

Take this image, for example:


It is a part of the silk icon set, 16x16 pixels and could be resized to 32x32 in several ways.



Using hq2x would be my first choice since it produces good results and doesn't take a lot of time to use. If someone knows how to program a Photoshop plugin it would take even less time. :-) If we decide to use the silk icon set, I would gladly take on the task to produce 32 pixel versions of the icons.

As for
Also, about native look and feel. I personally feel like it is good to use the native APIs for control rendering (as wxWidgets does) because what if the user has a custom look installed or made their own look and feel. Even if we styled a GTK+ app to look like Windows XP or whatever, the program would then look like Windows XP instead of their custom style.

Oh, I just hate it when that happens. I struggle hard to get away from the horrid XP style and some programs just won't respond. What's even worse is when you stumble upon a program or plugin who has an even uglier GUI, often taken from early betas of *nix systems where pixels were Gods and actual image quality was something other people did.

Making the program GUI as close to 100% native is a very good goal indeed.
Logged

"Cleverly disguised as an original signature..."
rageboy
Jeweller
*****
Posts: 305

Ankit Singla


« Reply #29 on: May 26, 2007, 06:44:32 pm »

I can't comment on GTK and I've never heard of QT4. As long as it's cross-platform, I have no complaints. I'm very open to learning a new API. Comment on CE being quick, though--and this is mostly with regards to the 3.72 beta: It seems to take longer, especially if I need to manually tell Windows to pick CE instead of Notepad (as in I needed to check the "Always use this program" box in the open with dialog). This might have something to do with CE's associations breaking with the 3.72 I have, but even with 3.70, I started experiencing a slow-down eventually that Notepad didn't give me. It wasn't unbearable (about a second or two slower than Notepad, *maybe*), so I didn't mind, but the same can't be said about the 3.72 delay.

This was a result of me not compiling in release mode or something, because I recompiled, and it's back to normal. I think the associations shouldn't have broken only for debug mode though. That was kinda weird.
Logged
Pages: 1 [2]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.099 seconds with 18 queries.