Thanks!
-deech
The Windows theme is released as part of the standard windows
installer. The GNOME theme has not yet been released, but is
currently in the final development stages and should be released
separately after the next GUI release.
Both themes make GNUstep blend very well with the host environment.
GC
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>
--
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://wiki.gnustep.org/index.php/Screenshots
In Gnome you can configure GNUstep to not use AppIcons and MiniWindows
with (in a shell):
defaults write NSGlobalDomain GSAppOwnsMiniwindow NO
defaults write NSGlobalDomain GSSuppressAppIcon YES
or with SystemPreferences.
About the menu in Window, you can use this in apps that support this
style. This mean, apps that provides a main window when are launched.
Based document aplications can be configured to open an empty document
to put the menu. However, the current gnustep packages can't handle
several menus (if the user open more than one documents) so you need
handle these menus in that case (for example. updating the "Windows"
menu and the "Open Recent"). You can check Gemas.app, that works fine on
Windows and Gnome:
http://wiki.gnustep.org/index.php/Gemas.app
GC
--
Do you mean having the Windows theme set to WIndows Classic and using WinUXTheme in GNUstep? It worked OK last time I checked, but it could use some improvements to the colour mappings and border style mappings.
Eric
yes and no. Technically, the windows native theme cannot support
directly the "classic" theme. Akin to GNUstep itself, the "classic"
theme in Windows is not a theme drawn by the WinUX DLL, it is drawn as a
"fallback" without it. Since our windows theme relies on said DLL, it
cannot draw it directly.
I understand your longing for such a theme under windows: as soon as I
touch a Windows XP or Windows Vista PC for more than a couple of
minutes, I switch back to the ol' NT theme. And I have to work with
Windows every day...
The windows NT theme is not very different from GNUstep itself in terms
of design, since it was copied quite brutally from NeXT. The interface
guidelines are of course very different (CUA...), scrollbars, menus...
Your bet could be the "Windows Classic" theme of GAP which currently
tries to be a pure pixmap theme. Try it, it is not officially released
yet not even as a 0.1 version because our theming engine and native
in-windows menu support still have too many limitations and bugs.
That's also why other themes are languishing in GAP.
The window native theme work partially around the menu problem by using
the native windows menus.
Eventually part of the "Window classic" theme are becoming a fall-back
inside the windows native theme...
So you see a small complicated maze where in the past 2 years there was
progress, but I feel still too little to announce something for general
usage. Try, things might work for your specific application.
Cheers,
Riccardo
Stefan Bidi wrote:
> I've been meaning to ask this for some time... is there any plan to
> support the Windows Classic theme?
>
> On Sat, Jun 25, 2011 at 12:48 AM, Gregory Casamento
> <greg.ca...@gmail.com <mailto:greg.ca...@gmail.com>> wrote:
>
> Aditya,
>
> The Windows theme is released as part of the standard windows
> installer. The GNOME theme has not yet been released, but is
> currently in the final development stages and should be released
> separately after the next GUI release.
>
> Both themes make GNUstep blend very well with the host environment.
>
> GC
>
>
radiobuttons should work... they did last time I tried, I'll check that,
perhaps things have changed after Eric's changes in gui.
Riccardo
I believe the best course of action here is to expand the WinUXTheme
to support the classic theme on Windows properly by using bitmaps when
that particular theme is chosen. Switching manually between the
WinUXTheme and the "Windows Classic Theme" which resides in GAP is
somewhat clunky.
GC
--
I believe getting them to work separately well enough so that they can
be released is much more important. I don't consider either of them
presentable.
I want the windows classic theme to work alone: it enables to use it on
windows 2000 or ReactOS for example or even other Unix distributions as
a CUA-compliant theme. If you use fvwm with a windows style, the theme
would be your best bet probably
Once they will work, we can think if merging them makes sense. It needs
some tinkering when both versions of the theme have a bitmap.
In Italy we say: don't make a stride longer than your leg.
Riccardo
Nevertheless the only step forward for the WinUXTheme right now is to
fix this bug in the way I suggested. Yes, there are bugs, but this is
by far the most prominent one.
GC
--
For me, the biggest bug is the handling of document based application
with no untitled document, we discussed that many times. Fixed that it
would be releasable and available for general use. There are many otehr
minor things which can be improved, liek certain controls,
auto-generation of icns, etc.
-R
The functionality you're referring to shouldn't even be part of the
theme, but something which needs to be implemented in GUI itself.
This is not the only missing feature in theming right now, there are
quite a few:
1) Cleanly switching from theme to theme when in-window menus are involved.
2) Unloading theme images between themes. When theme A loaded if
theme B doesn't have images for some of the widgets then theme A's
images are used instead of the default theme's images as may have been
intended.
3) Notification of theme switch when working with native themes such
as Windows or GNOME. This where the OS level theme changes, but the
GNUstep theme maintains the old look because it hasn't been notified
that the theme has changed.
There are quite a few more. I believe these have all been entered
into the bug tracker.
GC
--
On 06/27/11 03:01, Gregory Casamento wrote:
> Riccardo,
>
>
> 1) Cleanly switching from theme to theme when in-window menus are involved.
Yes, this is especially noticeable when native in-windows menus are
used, but that goes along with 3)
> 2) Unloading theme images between themes. When theme A loaded if
> theme B doesn't have images for some of the widgets then theme A's
> images are used instead of the default theme's images as may have been
> intended.
Afaik, unloading was implemented by Richard, but somehow it doesn't work
(anymore).
> 3) Notification of theme switch when working with native themes such
> as Windows or GNOME. This where the OS level theme changes, but the
> GNUstep theme maintains the old look because it hasn't been notified
> that the theme has changed.
Associated with that there is the release of the native resources, like
the native in-window menus.
> There are quite a few more. I believe these have all been entered
> into the bug tracker.
Yep, there are others, but the one you mentioned are the "major" ones.
-R
> Hi,
>
> On 06/27/11 03:01, Gregory Casamento wrote:
>> Riccardo,
>>
>>
>> 1) Cleanly switching from theme to theme when in-window menus are involved.
> Yes, this is especially noticeable when native in-windows menus are used, but that goes along with 3)
>> 2) Unloading theme images between themes. When theme A loaded if
>> theme B doesn't have images for some of the widgets then theme A's
>> images are used instead of the default theme's images as may have been
>> intended.
> Afaik, unloading was implemented by Richard, but somehow it doesn't work (anymore).
Yes ... eighteen months ago IIRC, but there have probably been a lot of changes in theming that I haven't been involved with since then...
The basic principle was simple.
When you load a theme, all the images for that theme are installed.
When you unload a theme, all the images for the default theme are installed (which means all system images)
When you change themes, you have a sequence of unloading the old theme (which cleans out its images) and loading the new.
Now, it's possible to have glitches with this caused by code outside the theming system ... if code makes a *copy* of a system image (rather than retaining it), and caches and re-uses that copy. There may be some such bugs in odd apps or even odd places in the gui library. If so, they should either:
1. not copy the system images, just use them as required .... the best option unless we *know* there is a performance issue.
2. where they must do something like keeping a scaled or otherwise modified copy of a system image for performance, they should have the code observe theme loading notifications and regenerate their cache when a new theme is loaded ... this is a general principle of theme aware software, without which no theming system can work properly.
-deech
aditya siram wrote:
> Thank you all for the information. Is there currently an open-source
> application created with GnuStep that runs with a native look-and-feel
> on Windows, Linux and Mac? It would be nice if there were some
> reference point.
>
First of all: Linux doesn't have a native look-and-feel at all... For
me, Linux or BSD means GNUstep. Many people use GNOME and this is why
there is a GTK/Gnome theme in the works, but using GNUstep on Linux is
100% native.
Said that, I work on several applications which run both on GNUstep and
on Mac natively compiled on both. Some of them were even GNUstep
applications ported from GNUstep to Mac!
Several of them work on Windows too, also with the native windows theme,
but not all (or not yet because I didn't port them: mingw doesn't
provide a full POSIX environment, so adjustment to the code may be
necessary).
For a reference and many Screenshots check out my own blog,
http://multixden.blogspot.com/ and the GNUstep Application Project.
My first Cocoa+GNUstep application was and still is PRICE,
http://price.sf.net : since release 0.2 it has been designed to work on
both evnironments.
So do LaternaMagica, FTP, Vespucci, DataBasin, Graphos and many others.
Graphos started on GNUstep and has been perfectly ported, you may check
some screenshots here:
http://gap.nongnu.org/graphos/index.html#screenshots
Grr, the RSS reader, was a GNUstep app ported too:
here on GNUstep:
http://gap.nongnu.org/grr/index.html
and here natively on windows with one of the first working native theme
bundles:
http://multixden.blogspot.com/2010/02/grr-working-on-windows.html
You may notice the native window decorations and the native menus. I
don't have a Mac screenshot at hand, but it works and I also provide a
binary.
The Game GShisen runs everywhere too:
Check yourself here:
http://gap.nongnu.org/gshisen/index.html
So you see, it has been done before, it works and there are many degrees
of freedom and customization.
Cheers.
Riccardo
-deech
it is usable, the state depends on the application you use, for some it
will work flawlessly already. It is available from the lain gnustep
repository.
In any case I encourage you to use the GNUstep user interface because it
is just superior to CUA guidelines :) The theme is thought to easy
integration one app in a different environment.
For a complete desktop experience instead, use the standard theme or its
variations (like NeOS or Sleek)
Riccardo
In order to find examples of a single code-base using different themes
I have downloaded the source for a number of cross-platform
applications:
GraphOS, Grr, GShisen, Gemas
However it is not apparent to me where to look for the code that deals
with different platforms. For example how would I build an executable
for Windows or Gnome using the source? I would appreciate if someone
could point me to a file in any of these application where is
different GUI behavior invoked based on platform.
Thanks for all your help.
-deech
On Thu, Jun 30, 2011 at 10:23 AM, Riccardo Mottola
the trick is that there is no code involved!
Graphos, for example is perfectly native on Mac, the same is true for
Grr and GShisen.
The way this is accomplished is that there are
* two different "projects" one for ProjecectCenter (with makefiles) and
one for XCode
* two different interface sets: Gorm files and NIB files (this is not
necessary for apps which do not use interface files but code the
interface. Also you can use NIBs in GNustep but they don't look perfect
and native, so this is the most expensive but most "perfect" approach)
* the code base is about 100% the same. The small differences are
handled with #ifdefs in the applications which need that
The effect is that when you build on Mac you build with Xcode and have a
true mac app.
On Linux and Windows, your application will have the default GNUstep
theme (which essentially matches WindowMaker)
To make the GNUstep application feel at home in Windows or GNOME (or
other environments) you need a Theme. Currently themes for Windows and
GNOME are work in progress.
These themes handle the native bits for all applications and they are
not needed in the application.
Riccardo
Is there a tutorial showing how to build a GNUstep application using
the GTK or Windows theme? I realize they are not done, but if they
work even halfway well I'd be interested in using them.
-deech
as far as I know, there is no tutorial around on how to "package" an
application in a self-contained package containing gnustep and the theme.
However, to test the look and see how well the certain application
works, install GNUstep in the most common way on that platform.
Get the theme and install it. (make install should be enough, but you
can drag it into Library/Themes, either of the System, Local or even
your own User domain)
The themes are available in our modules under plugins/themes:
"GnomeTheme" and "WinUXTheme"
You can set the theme system-wide with system preferences and the themes
module.
You can also start your application, go in the info panel, click on the
"theme" link and a selectionpanel will appear. Once you set it, it will
be set only for that specific application.
(At the end, both procedures just write a default, one in the global
domain, one for the app domain).
Please bear in mind that while dynamic theme switching is in theory
supported, themes with "native" resources as menus, etc.. might not
load/unload properly. Restart your application.
Riccardo
Thanks for your quick response.
Is there a tutorial showing how to build a GNUstep application using
the GTK or Windows theme? I realize they are not done, but if they
work even halfway well I'd be interested in using them.
-deech
On Fri, Jul 15, 2011 at 10:31 AM, Riccardo Mottola
<riccardo...@libero.it> wrote:> Hi Deech,
>
> the trick is that there is no code involved!
>
> Graphos, for example is perfectly native on Mac, the same is true for Grr
> and GShisen.
>
> The way this is accomplished is that there are
> * two different "projects" one for ProjecectCenter (with makefiles) and one
> for XCode
> * two different interface sets: Gorm files and NIB files (this is not
> necessary for apps which do not use interface files but code the interface.
> Also you can use NIBs in GNustep but they don't look perfect and native, so
> this is the most expensive but most "perfect" approach)
> * the code base is about 100% the same. The small differences are handled
> with #ifdefs in the applications which need that
>
> The effect is that when you build on Mac you build with Xcode and have a
> true mac app.
>
> On Linux and Windows, your application will have the default GNUstep theme
> (which essentially matches WindowMaker)
>
> To make the GNUstep application feel at home in Windows or GNOME (or other
> environments) you need a Theme. Currently themes for Windows and GNOME are
> work in progress.
> These themes handle the native bits for all applications and they are not
> needed in the application.
>
>
> Riccardo
>
> On 07/15/11 17:03, aditya siram wrote:
>>
>> I am interested in GNUStep mainly as cross-platform toolkit that looks
>> good on Windows, Linux (Gnome and WindowMaker) and Mac.
>>
>> In order to find examples of a single code-base using different themes
>> I have downloaded the source for a number of cross-platform
>> applications:
>> GraphOS, Grr, GShisen, Gemas
>>
>> However it is not apparent to me where to look for the code that deals
>> with different platforms. For example how would I build an executable
>> for Windows or Gnome using the source? I would appreciate if someone
>> could point me to a file in any of these application where is
>> different GUI behavior invoked based on platform.
>>
>> Thanks for all your help.
>>
>> -deech
>>
>>>
>
>
On Fri, Jul 15, 2011 at 10:50 AM, Riccardo Mottola
<riccardo...@libero.it> wrote:
> Hi,
>
> as far as I know, there is no tutorial around on how to "package" an
> application in a self-contained package containing gnustep and the theme.
>
> However, to test the look and see how well the certain application works,
> install GNUstep in the most common way on that platform.
> Get the theme and install it. (make install should be enough, but you can
> drag it into Library/Themes, either of the System, Local or even your own
> User domain)
>
> The themes are available in our modules under plugins/themes:
> "GnomeTheme" and "WinUXTheme"
>
> You can set the theme system-wide with system preferences and the themes
> module.
>
> You can also start your application, go in the info panel, click on the
> "theme" link and a selectionpanel will appear. Once you set it, it will be
> set only for that specific application.
>
> (At the end, both procedures just write a default, one in the global domain,
> one for the app domain).
>
> Please bear in mind that while dynamic theme switching is in theory
> supported, themes with "native" resources as menus, etc.. might not
> load/unload properly. Restart your application.
>
> Riccardo