Mailing List Archive

On Nov 25, 2005, at 4:19 PM, dirk.schoenberger@sz-online.de wrote:

> Hi,
>
> some time ago there was a lengthy thread about the road ahead, with
> some
> interesting discussion about a hopefully better integration of
> Gentoo and
> OSX. In some unrelated, but perhaps nevertheless interesting events I
> stumbled across a couple of interesting topic which perhaps could
> help in
> achieving such better integration.
>
> JUst FYI, a better integration of Gentoo into Aqua/OSX starts at least
> that I could use some kind of GUI, instead of having to resort to the
> command line ;)
>
> A good starting point would be the following link
> http://livingcode.blogspot.com/2004_11_01_livingcode_archive.html
>
> The idea is to provide GUI frontends to Gentoo applications using
> Python
> bindings to AppKit/Cocoa, and the use of Renaissance, a declarative
> GUI
> approach implemented as part of the GNUstep project
> (http://www.gnustep.org)

Where 'Gentoo applications' == the portage UI itself ? Or are you
talking about actually wrapping arbitrary packages in a GUI?

The former, should definitely wait until portage 3 (saviour) is here,
as that will be the first portage to actually have an API.

The latter, is a completely crazy idea, but if you think you can pull
it off, more power to ya ;)

Sorry, I guess I don't understand the goal completely...

--Kito


--
gentoo-osx@gentoo.org mailing list

> > The idea is to provide GUI frontends to Gentoo applications using
> > Python
> > bindings to AppKit/Cocoa, and the use of Renaissance, a declarative
> > GUI approach implemented as part of the GNUstep project
> > (http://www.gnustep.org)

> Where 'Gentoo applications' == the portage UI itself ? Or are you
> talking about actually wrapping arbitrary packages in a GUI?

In fact, both. the first step would obviously be to build some basic GUI
around some interesting console applications.
The wrapper could be written in Python (or another scripting language
which has ObjC bindings, which I have not further investigated, yet) and
calls the console commands. Additional points for parsing the tools output
andshowinfg the result in the wrapper GUI.

The next step would be to implement Gento specific backends, for querying
the Gentoo database and installing / deinstalling / reinstalling packages.
This could be implemented by calling Gentoo scripts, or a C / Python /
whatever level, as soon it is available.

The advantage against the current manual installation would be that you
can rely on the Gentoo package management facilities, which I came to miss
after my last experiments. Things like automatic version updates,
dependency management, the possibility to actual unistall stuff....

By using renaissance as your frontend system, you can achieve some nice
cross platform abilities which leads to less code needed to be maintained
by the gentoo-osx people.

> The former, should definitely wait until portage 3 (saviour) is here,
> as that will be the first portage to actually have an API.

I assume there already exist some scripts which could be used to query the
Gentoo database? Something like gentoo-toolkit?
Now all is needed is a way to exec a shell script via Python.

> The latter, is a completely crazy idea, but if you think you can pull
> it off, more power to ya ;)

It is possibly to implement the actual script without using Gentoo, so
this I could do without help. For integrating this stuff and porting the
needed prerequisites, I think I would hae to ask for help from Gentoo
developers... ;)



Regards
Dirk


--
gentoo-osx@gentoo.org mailing list

On Fri, 25 Nov 2005, Kito wrote:

>
> Where 'Gentoo applications' == the portage UI itself ? Or are you talking
> about actually wrapping arbitrary packages in a GUI?
>
> The former, should definitely wait until portage 3 (saviour) is here, as that
> will be the first portage to actually have an API.
>
> The latter, is a completely crazy idea, but if you think you can pull it off,
> more power to ya ;)

It isn't as crazy as it sounds. Apple has been wrapping GUIs around CLI
tools since MPW's Commando, and then later in A/UX. These days we can use
AppleScript to run shell commands, which is particularly useful with
droplets. Tiger's Automator has also been used to leverage CLI tools [1].

Dirk's Renaissance [2] suggestion is nice because it is portable (would
work under linux) and it is open. Other tools for doing this are not all
free and open [3].

-f

[1] http://www.pixelglow.com/shellac/

[2] http://www.gnustep.it/Renaissance/

[3]
http://sveinbjorn.sytes.net/software
http://www.wsanchez.net/software/

http://home.tiscali.cz:8080/ucsi-sw/products.html
http://www.prefab.com/



> Sorry, I guess I don't understand the goal completely...
>
> --Kito
>
>
>
--
gentoo-osx@gentoo.org mailing list

On 26-11-2005 00:08:02 +0100, dirk.schoenberger@sz-online.de wrote:
> > > The idea is to provide GUI frontends to Gentoo applications using
> > > Python
> > > bindings to AppKit/Cocoa, and the use of Renaissance, a declarative
> > > GUI approach implemented as part of the GNUstep project
> > > (http://www.gnustep.org)
>
> > Where 'Gentoo applications' == the portage UI itself ? Or are you
> > talking about actually wrapping arbitrary packages in a GUI?
>
> In fact, both. the first step would obviously be to build some basic GUI
> around some interesting console applications.

Like? What kinds of applications are you thinking of here? Just help
me with ideas here, because I wouldn't see the use of a GUI wrapper for
sed. A GUI for pdflatex on the other hand is nice, but already exists
(TeXshop).

> The wrapper could be written in Python (or another scripting language
> which has ObjC bindings, which I have not further investigated, yet) and
> calls the console commands. Additional points for parsing the tools output
> andshowinfg the result in the wrapper GUI.
>
> The next step would be to implement Gento specific backends, for querying
> the Gentoo database and installing / deinstalling / reinstalling packages.
> This could be implemented by calling Gentoo scripts, or a C / Python /
> whatever level, as soon it is available.

Interesting at this point may be extending/porting the GUI around
libconf, a Gentoo-ish project by dams. But that is only one of course.
If I recall correctly there is some daft portage GUI as well now, but I
think something like FinkCommander would look better (although
FinkCommander is anything but intuitive).

> The advantage against the current manual installation would be that you
> can rely on the Gentoo package management facilities, which I came to miss
> after my last experiments. Things like automatic version updates,
> dependency management, the possibility to actual unistall stuff....

Maybe I misunderstand you here, but what were your last experiments? As
far as I know, Portage can do updates, dependency management and
uninstall packages. What would you like to add here?

> By using renaissance as your frontend system, you can achieve some nice
> cross platform abilities which leads to less code needed to be maintained
> by the gentoo-osx people.

dirk++ :)

> > The former, should definitely wait until portage 3 (saviour) is here,
> > as that will be the first portage to actually have an API.
>
> I assume there already exist some scripts which could be used to query the
> Gentoo database? Something like gentoo-toolkit?
> Now all is needed is a way to exec a shell script via Python.

Using equery, or eix (a C implementation of portage which should be much
faster -- I'm not sure if it completely works) you should be able to get
a lot of data you need. Using some sane interface model, you'd be able
to use the Portage (Python?) API lateron very easily I presume.

> > The latter, is a completely crazy idea, but if you think you can pull
> > it off, more power to ya ;)
>
> It is possibly to implement the actual script without using Gentoo, so
> this I could do without help. For integrating this stuff and porting the
> needed prerequisites, I think I would hae to ask for help from Gentoo
> developers... ;)

Hmmm... Interesting!

I'd like to see your plans here, like what you envision, and what you
think would be necessary to do. Where exactly you'd need help, and what
you can deliver. :) You can always do your own thing, and I'd like to
encourage that. Keep us posted!

--
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
--
gentoo-osx@gentoo.org mailing list

> > In fact, both. the first step would obviously be to build some basic GUI
> > around some interesting console applications.

> Like? What kinds of applications are you thinking of here? Just help
> me with ideas here, because I wouldn't see the use of a GUI wrapper for
> sed. A GUI for pdflatex on the other hand is nice, but already exists
> (TeXshop).

I agreeg TeX is too complicated for my ideas, and grep is not really
useful. At least currently I don't see no way to implement OpenStep
services via Renaissance , which would change this.

Applications I would like to GUIfy include
- wget (downloaders are useful outside outomated scripts, too)
- WordNet resp. queequeg
- image to vector applications like autotrace resp. potrace

More complex GUIs I could imagine e.g for
- ImageMagick

(the latter would need a new kind of GUI, not so much form based, more
task based - you could have a list of taks, where you could e.g add a task
like "resize" or "reduce colours".
The given task list could be applied to one or more images, in some kind
of "batch mode operation"

> > The next step would be to implement Gento specific backends, for querying
> > the Gentoo database and installing / deinstalling / reinstalling
packages.
> > This could be implemented by calling Gentoo scripts, or a C / Python /
> > whatever level, as soon it is available.

> Interesting at this point may be extending/porting the GUI around
> libconf, a Gentoo-ish project by dams. But that is only one of course.
> If I recall correctly there is some daft portage GUI as well now, but I
> think something like FinkCommander would look better (although
> FinkCommander is anything but intuitive).

Thats way I would like to retain a Gentoo User Interface until later.
Basically I could see three possible GUIs
- a form based GUI around emerge commands, in a complex multi-tab dialog
- a simple list where you can see the list of latest ebuild changes,
something like "keep your system uptodate"
- a complex application with multiple buttons, lists, text entries where
you can see a see all ebuild and their metadata (version, licence, USE
flags...)
Something like a rich client application for packages.gentoo.org, with
the added functionality to start a emerge, emerge -C, emerge -u for the
selected packages

The last two GUIs you can see in some apt frontends, like e.g in Ubuntu
(written in C / Gtk)

I have never seen FinkCommander

> > The advantage against the current manual installation would be that you
> > can rely on the Gentoo package management facilities, which I came to
> > miss after my last experiments. Things like automatic version updates,
> > dependency management, the possibility to actual unistall stuff....

> Maybe I misunderstand you here, but what were your last experiments? As
> far as I know, Portage can do updates, dependency management and
> uninstall packages. What would you like to add here?

I don't intend to criticize portage her, on the contrary. Gentoo is a
shining example for dependency management done right ;)
But because some applications I played around lately either were not
available in Gentoo (Renaissance framework for OSX, py2app, Python wrapper
for Objective C), or were not really useful (I tried a GUI TeX frontend,
where I needed to install a LateX distribution, where I could choose
between fink, darwin ports and some tool called iInstaller, Gentoo was not
supported)

For the former I had to resort to .mpkgs, .dmgs with readmes to copy some
files to /System/Library, or downright hand crafted python install
scripts.

All of these way have no idea about having a running, maintainable system,
with components which can depend upon, and which can be removed.

Regards
Dirk

--
gentoo-osx@gentoo.org mailing list

> > In fact, both. the first step would obviously be to build some basic GUI
> > around some interesting console applications.

> Like? What kinds of applications are you thinking of here? Just help
> me with ideas here, because I wouldn't see the use of a GUI wrapper for
> sed. A GUI for pdflatex on the other hand is nice, but already exists
> (TeXshop).

What I miss in my last mail

- a frontend to a website cheker. Currently I found weblint (written in
Perl, which I got to emerge) and net-analyzer/linkchecker, which doesn't
work (without using progressive, because it depends on Python 2.4)

> > It is possibly to implement the actual script without using Gentoo, so
> > this I could do without help. For integrating this stuff and porting the
> > needed prerequisites, I think I would hae to ask for help from Gentoo
> > developers... ;)

> Hmmm... Interesting!

> I'd like to see your plans here, like what you envision, and what you
> think would be necessary to do. Where exactly you'd need help, and what
> you can deliver. :) You can always do your own thing, and I'd like to
> encourage that. Keep us posted!

I could see multiple things, in something like the following order

1) a port of Renaissance to cocoa. Because there already exist a binary
distribution, porting must be possible. Perhaps a special USE flag is
needed, for somebody who want to keep parallel versions for GNUstep/X and
Cocoa in parallel.

2) check if it is useful to create ebuilds for py2app and PyObjc. I am not
quite sure about the dependencies these packages should have. It would be
good if they are not Macos specific, but could be used in Gentoo / Linux.
Possbly of interest for GNUstep.

3) I would see if I could do my frontend ideas, and if I am successful, I
would like to add these to the ebuilds. I would like to see some sepecial
USE flags (USE=gui?) where these frontends are emerged. Again, by using
the packages, this could be interesting for Gentoo Linux too (even if I
think that there are not so many people interested in a GNUstep based GUI,
yet ;))

4) discuss the possibilities for a Gentoo GUI frontend - check for needed
features and possible solutions. If it makes sense to use my proposed
solution, I would be fine with helping with an implementation.

Regards
Dirk
--
gentoo-osx@gentoo.org mailing list

On 27-11-2005 01:43:29 +0100, dirk.schoenberger@sz-online.de wrote:
> I agreeg TeX is too complicated for my ideas, and grep is not really
> useful. At least currently I don't see no way to implement OpenStep
> services via Renaissance , which would change this.
>
> Applications I would like to GUIfy include
> - wget (downloaders are useful outside outomated scripts, too)
> - WordNet resp. queequeg
> - image to vector applications like autotrace resp. potrace

Ok. Now I get what you want. For the image converting applications,
you might want to go for some 'drop file on' solution, like
Photoshop has. You simply drop a file on the icon, and it's being
converted somehow. I think this is quite generic somehow. Interesting!

> More complex GUIs I could imagine e.g for
> - ImageMagick

For sure! But aren't there attempts for this yet? I mean, is this idea
brand new, or are there already a few apps that are some sort of skin
for ImageMagick, but just written in something that doesn't work very
well on OSX?

> (the latter would need a new kind of GUI, not so much form based, more
> task based - you could have a list of taks, where you could e.g add a task
> like "resize" or "reduce colours".

This sounds exactly like the properties of Automator. I never toyed
with it, but it it sold as ultimate tool for 'intelligent' task
automation. Maybe generating Automator scripts would be a first step?

> The given task list could be applied to one or more images, in some kind
> of "batch mode operation"

Like the drop thing I described before, it's easy to select multiple
files and drop them at once on the icon, of course.

> > Interesting at this point may be extending/porting the GUI around
> > libconf, a Gentoo-ish project by dams. But that is only one of course.
> > If I recall correctly there is some daft portage GUI as well now, but I
> > think something like FinkCommander would look better (although
> > FinkCommander is anything but intuitive).
>
> Thats way I would like to retain a Gentoo User Interface until later.
> Basically I could see three possible GUIs
> - a form based GUI around emerge commands, in a complex multi-tab dialog

I think this already exists, just an extensive form with options, bells
and whistles.

> - a simple list where you can see the list of latest ebuild changes,
> something like "keep your system uptodate"

Like the FinkCommander screen, right?

> - a complex application with multiple buttons, lists, text entries where
> you can see a see all ebuild and their metadata (version, licence, USE
> flags...)
> Something like a rich client application for packages.gentoo.org, with
> the added functionality to start a emerge, emerge -C, emerge -u for the
> selected packages

Ok, so that's the full FinkCommander functionality.

> The last two GUIs you can see in some apt frontends, like e.g in Ubuntu
> (written in C / Gtk)
>
> I have never seen FinkCommander

Good, good, good!!!! :) However, you should take a look at their
screenshots, because it's exactly what you describe.

> > Maybe I misunderstand you here, but what were your last experiments? As
> > far as I know, Portage can do updates, dependency management and
> > uninstall packages. What would you like to add here?
>
> I don't intend to criticize portage her, on the contrary. Gentoo is a
> shining example for dependency management done right ;)
> But because some applications I played around lately either were not
> available in Gentoo (Renaissance framework for OSX, py2app, Python wrapper
> for Objective C), or were not really useful (I tried a GUI TeX frontend,
> where I needed to install a LateX distribution, where I could choose
> between fink, darwin ports and some tool called iInstaller, Gentoo was not
> supported)

Ok, like that. I think this is partly an image and availability issue.
We know not everything is right and works, and many packages have never
been tried/keyworded. We're a bit unknown, and as long as we're not
really able to be a worthy alternative for Fink, we'll never grow beyond
it. I deliberately chose to keep things a bit quiet right now, since we
need to get ourselves on the rails (and organised) here first. Though
your point is valid, but the docs should all say that we're
'experimental'.

> For the former I had to resort to .mpkgs, .dmgs with readmes to copy some
> files to /System/Library, or downright hand crafted python install
> scripts.
>
> All of these way have no idea about having a running, maintainable system,
> with components which can depend upon, and which can be removed.

Nice, eh? :)

So, conclusion is, we have a long way to go. Any help is welcome!

--
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
--
gentoo-osx@gentoo.org mailing list

On 27-11-2005 09:52:20 +0100, dirk.schoenberger@sz-online.de wrote:
> > > In fact, both. the first step would obviously be to build some basic GUI
> > > around some interesting console applications.
>
> > Like? What kinds of applications are you thinking of here? Just help
> > me with ideas here, because I wouldn't see the use of a GUI wrapper for
> > sed. A GUI for pdflatex on the other hand is nice, but already exists
> > (TeXshop).
>
> What I miss in my last mail
>
> - a frontend to a website cheker. Currently I found weblint (written in
> Perl, which I got to emerge) and net-analyzer/linkchecker, which doesn't
> work (without using progressive, because it depends on Python 2.4)

OT: did you install Python 2.4 in the end?

> > > It is possibly to implement the actual script without using Gentoo, so
> > > this I could do without help. For integrating this stuff and porting the
> > > needed prerequisites, I think I would hae to ask for help from Gentoo
> > > developers... ;)
>
> > Hmmm... Interesting!
>
> > I'd like to see your plans here, like what you envision, and what you
> > think would be necessary to do. Where exactly you'd need help, and what
> > you can deliver. :) You can always do your own thing, and I'd like to
> > encourage that. Keep us posted!
>
> I could see multiple things, in something like the following order
>
> 1) a port of Renaissance to cocoa. Because there already exist a binary
> distribution, porting must be possible. Perhaps a special USE flag is
> needed, for somebody who want to keep parallel versions for GNUstep/X and
> Cocoa in parallel.

The keyword aqua comes to mind... Kito and I had a discussion about it
the other day, but the idea is right I think.

> 2) check if it is useful to create ebuilds for py2app and PyObjc. I am not
> quite sure about the dependencies these packages should have. It would be
> good if they are not Macos specific, but could be used in Gentoo / Linux.
> Possbly of interest for GNUstep.

Sure. Objective-C is just something which you should have compiled when
emerging gcc, but GNUstep users (like me, surprise, eh?) will probably
be able to benefit from these efforts. Question remains who else could
benefit from it, because the number of Gentoo/GNUstep users is rather
small, IMHO.

> 3) I would see if I could do my frontend ideas, and if I am successful, I
> would like to add these to the ebuilds. I would like to see some sepecial
> USE flags (USE=gui?) where these frontends are emerged. Again, by using
> the packages, this could be interesting for Gentoo Linux too (even if I
> think that there are not so many people interested in a GNUstep based GUI,
> yet ;))

If I recall correctly, there are special eclasses that for instance
allow to place an icon on the desktop of the user (transparently to what
window manager the user uses). I could imagine that we would use a
similar structure where we install such small drop-in or little script
in a place, only if on OSX (or GNUstep, Gnome, KDE?). You can see it as
addon.

> 4) discuss the possibilities for a Gentoo GUI frontend - check for needed
> features and possible solutions. If it makes sense to use my proposed
> solution, I would be fine with helping with an implementation.

The GentooUI (pronounced as 'gentoo-e' ? :p ), or iGentoo can be
developed in a separate track from the others. However, it would be a
waste if it would be developed such that nothing of it can be reused for
other Gentoo/X projects.


--
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
--
gentoo-osx@gentoo.org mailing list

> > - image to vector applications like autotrace resp. potrace

> Ok. Now I get what you want. For the image converting applications,
> you might want to go for some 'drop file on' solution, like
> Photoshop has. You simply drop a file on the icon, and it's being
> converted somehow. I think this is quite generic somehow. Interesting!

Nice idea, but currently not doable, I am afraid. My ObjectiveC / Cocoa
knowledge is not upto task to do something as complicated as drag-and-drop
programming ;)

> > More complex GUIs I could imagine e.g for
> > - ImageMagick

> For sure! But aren't there attempts for this yet? I mean, is this idea
> brand new, or are there already a few apps that are some sort of skin
> for ImageMagick, but just written in something that doesn't work very
> well on OSX?

Most (GUI) attempts I know try to wrap around the Image Magick API and try
to build a document centric (or a type manager / image database)
For document centric there exists GraphicConverter, while for type manager
there exist iPhoto.
Both are not really interesting to me.

What I miss on Mac is something like IrfanView's (on Windows) batch
conversion GUI.

> This sounds exactly like the properties of Automator. I never toyed
> with it, but it it sold as ultimate tool for 'intelligent' task
> automation. Maybe generating Automator scripts would be a first step?

I think Automator is a dead end, at least currently.
- Tiger only
- only linear workflows
- I have not so many recurring tasks which would require building automator
like workflows.

> > - a simple list where you can see the list of latest ebuild changes,
> > something like "keep your system uptodate"

> Like the FinkCommander screen, right?

In fact more something like that ;) http://www.gnomejournal.org/images/45.png

> > Something like a rich client application for packages.gentoo.org, with
> > the added functionality to start a emerge, emerge -C, emerge -u for the
> > selected packages

> Ok, so that's the full FinkCommander functionality.
Yes.

> > The last two GUIs you can see in some apt frontends, like e.g in Ubuntu
> > (written in C / Gtk)
> >
> > I have never seen FinkCommander

> Good, good, good!!!! :) However, you should take a look at their
> screenshots, because it's exactly what you describe.

FinkCommander seems to be a good candidate for a "data waste / information
overload" type application. I don't think such a GUI is really suitable
for a large repository like Gentoo, with thousands of applications.
Besides, I am more a fan of icon list views or OpenStep like multi-column
lists, instead of table based lists...

> OT: did you install Python 2.4 in the end?

No. If I currently need source packages which are not available for
Gentoo, I either install manually into /usr/local, or into really parallel
branches like /gnu.
progressive mode, or a Fink style managed /sw hierarchy, ar currently no
option for me.

> > 1) a port of Renaissance to cocoa. Because there already exist a binary
> > distribution, porting must be possible. Perhaps a special USE flag is
> > needed, for somebody who want to keep parallel versions for GNUstep/X
> > and Cocoa in parallel.

> The keyword aqua comes to mind... Kito and I had a discussion about it
> the other day, but the idea is right I think.

Fine. What is needed to get this started? I could try to compile / emerge
Renaissance and try to extract suitable flags for a Cocoa based ebuild.

> > good if they are not Macos specific, but could be used in Gentoo / Linux.
> > Possbly of interest for GNUstep.

> Sure. Objective-C is just something which you should have compiled when
> emerging gcc, but GNUstep users (like me, surprise, eh?) will probably
> be able to benefit from these efforts.

I would much prefer to be able to use a package.provided ObjectiveC
compiler...

> Question remains who else could benefit from it, because the number of
> Gentoo/GNUstep users is rather small, IMHO.

Good question, but something I cannot answer. My Python knowledge is
nearly zero.

> If I recall correctly, there are special eclasses that for instance
> allow to place an icon on the desktop of the user (transparently to what
> window manager the user uses).

If you use py2app, you get a app folder in the dist sub folder of your
python app root. I thought it was a good idea to copy this app folder
application into something like /Applications/Gentoo, in the installation
step of emerge.
No need to toy around with links, at least not on OSX, I think.

> The GentooUI (pronounced as 'gentoo-e' ? :p ), or iGentoo can be
> developed in a separate track from the others. However, it would be a
> waste if it would be developed such that nothing of it can be reused for
> other Gentoo/X projects.

Agreed on the "separate track".
I am not quite sure about the other part. From what I see, a GentooUI tool
(or at list something like a FinkCommander clone) is not much more than a
emerge output parser and pretty printer ;)
This means that the interesting / backend parts are already re-useable
(even more so if there exist an API instead of having to grep console
output), while the frontend part mostly are toolkit specific and not
useable.

Regards
Dirk
--
gentoo-osx@gentoo.org mailing list

On 27-11-2005 14:32:56 +0100, dirk.schoenberger@sz-online.de wrote:
> > > - image to vector applications like autotrace resp. potrace
>
> > Ok. Now I get what you want. For the image converting applications,
> > you might want to go for some 'drop file on' solution, like
> > Photoshop has. You simply drop a file on the icon, and it's being
> > converted somehow. I think this is quite generic somehow. Interesting!
>
> Nice idea, but currently not doable, I am afraid. My ObjectiveC / Cocoa
> knowledge is not upto task to do something as complicated as drag-and-drop
> programming ;)

I think the OS is your big friend here. If I'm not mistaken a drop
action is equal to typing on the command line:
open -a <app being dropped on> <file you dropped>

> > For sure! But aren't there attempts for this yet? I mean, is this idea
> > brand new, or are there already a few apps that are some sort of skin
> > for ImageMagick, but just written in something that doesn't work very
> > well on OSX?
>
> Most (GUI) attempts I know try to wrap around the Image Magick API and try
> to build a document centric (or a type manager / image database)
> For document centric there exists GraphicConverter, while for type manager
> there exist iPhoto.
> Both are not really interesting to me.
>
> What I miss on Mac is something like IrfanView's (on Windows) batch
> conversion GUI.

Ok. Question then is how Gentoo specific this is. Such application
would more or less sound like something which has it's own ebuild and
depends on imagemagick.

> I think Automator is a dead end, at least currently.
> - Tiger only
> - only linear workflows
> - I have not so many recurring tasks which would require building automator
> like workflows.

Ok.

> > > - a simple list where you can see the list of latest ebuild changes,
> > > something like "keep your system uptodate"
>
> > Like the FinkCommander screen, right?
>
> In fact more something like that ;) http://www.gnomejournal.org/images/45.png

Ah... (a lot) like SoftwareUpdate, or a tiny little bit like MS Windows Update.

> > > I have never seen FinkCommander
>
> > Good, good, good!!!! :) However, you should take a look at their
> > screenshots, because it's exactly what you describe.
>
> FinkCommander seems to be a good candidate for a "data waste / information
> overload" type application. I don't think such a GUI is really suitable
you got it!
> for a large repository like Gentoo, with thousands of applications.
I think their repo is larger at the moment, but it sucks, yes.
> Besides, I am more a fan of icon list views or OpenStep like multi-column
> lists, instead of table based lists...
I like the Finder giving you three views on the same data. For every
occasion it's own view ;)

> > OT: did you install Python 2.4 in the end?
>
> No. If I currently need source packages which are not available for
> Gentoo, I either install manually into /usr/local, or into really parallel
> branches like /gnu.
> progressive mode, or a Fink style managed /sw hierarchy, ar currently no
> option for me.

Why is a prefixed hierarchy (like Fink's /sw) not an option for you?
What is different in there from installing into /usr/local or /gnu?

> > The keyword aqua comes to mind... Kito and I had a discussion about it
> > the other day, but the idea is right I think.
>
> Fine. What is needed to get this started? I could try to compile / emerge
> Renaissance and try to extract suitable flags for a Cocoa based ebuild.

Sure! If you want to use it, (and it looks nice for Python people) we
should first port it. Perhaps grab the patches from those that made it
work on OSX, then see if we can put them in one ebuild, or need a
separate one. Having compiling sources that's always useful.

> > Sure. Objective-C is just something which you should have compiled when
> > emerging gcc, but GNUstep users (like me, surprise, eh?) will probably
> > be able to benefit from these efforts.
>
> I would much prefer to be able to use a package.provided ObjectiveC
> compiler...

You already have one. But Linux users by default don't.

> > Question remains who else could benefit from it, because the number of
> > Gentoo/GNUstep users is rather small, IMHO.
>
> Good question, but something I cannot answer. My Python knowledge is
> nearly zero.

Same here. And I'm not enough attracted to the appearance of the
language to actually try and learn it. I can understand it, that's all.

> > If I recall correctly, there are special eclasses that for instance
> > allow to place an icon on the desktop of the user (transparently to what
> > window manager the user uses).
>
> If you use py2app, you get a app folder in the dist sub folder of your
> python app root. I thought it was a good idea to copy this app folder
> application into something like /Applications/Gentoo, in the installation
> step of emerge.
> No need to toy around with links, at least not on OSX, I think.

Hmmm... that's indeed interesting.

> > The GentooUI (pronounced as 'gentoo-e' ? :p ), or iGentoo can be
> > developed in a separate track from the others. However, it would be a
> > waste if it would be developed such that nothing of it can be reused for
> > other Gentoo/X projects.
>
> Agreed on the "separate track".
> I am not quite sure about the other part. From what I see, a GentooUI tool
> (or at list something like a FinkCommander clone) is not much more than a
> emerge output parser and pretty printer ;)
> This means that the interesting / backend parts are already re-useable
> (even more so if there exist an API instead of having to grep console
> output), while the frontend part mostly are toolkit specific and not
> useable.

I follow your reasoning, and agree with it. I personally think this is
not very important to have right now, so if nobody feels like doing it
yet, nobody has to put efforts in it. Getting the Portage API would be
nice too, so we can wait I think.

--
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
--
gentoo-osx@gentoo.org mailing list

> > What I miss on Mac is something like IrfanView's (on Windows) batch
> > conversion GUI.

> Ok. Question then is how Gentoo specific this is. Such application
> would more or less sound like something which has it's own ebuild and
> depends on imagemagick.

I would not call a 100 line Python script or such an application...
But at least the ImageMagick wrapper is currently just creative thinking,
so there is not
really something to talk about.

> > In fact more something like that ;)
http://www.gnomejournal.org/images/45.png

> Ah... (a lot) like SoftwareUpdate, or a tiny little bit like MS Windows
Update.

Yes, SoftwareUpdate (I was not quite sure about the name of the app, on my
German system it is "Software Aktualisierung"

> > Besides, I am more a fan of icon list views or OpenStep like multi-column
> > lists, instead of table based lists...
> I like the Finder giving you three views on the same data. For every
> occasion it's own view ;)

Which doesn't really help if you want to be GNUstep compatible. From what
I know, on compatibility mode you are stuck with things like GNUstep
Workspace.app.
BTW, I believe finder is not written in ObjectiveC, so I am not quite sure
if multi-mode lists are possible in Cocoa / OpenStep at all.

> Why is a prefixed hierarchy (like Fink's /sw) not an option for you?
> What is different in there from installing into /usr/local or /gnu?

I think prefixed hierarchies make the system unclean. It is one thing if I
decide to install modules into such a hierarchy in order to get
interesting other modules compiled.
It is a whole another thing if I want to let automated tools untidy my
system ;)

> > I would much prefer to be able to use a package.provided ObjectiveC
> > compiler...

> You already have one. But Linux users by default don't.

I would think a working ObjectiveC compiler is a prerequisite for
compiling gnustep.
So perhaps gnustep-libs (or a meta package which could be solved by
gnustep-libs-devel or cocoa libs) would be the correct dependency?

> > Good question, but something I cannot answer. My Python knowledge is
> > nearly zero.

> Same here. And I'm not enough attracted to the appearance of the
> language to actually try and learn it. I can understand it, that's all.

I don't really like the language either, but the possibility to write an
portable application without either having to delve into proprietary XCode
stuff, or into GNUmake build system hell, it becomes rather attractive.
Its all a question of a comfortable tool chain...

> I follow your reasoning, and agree with it. I personally think this is
> not very important to have right now, so if nobody feels like doing it
> yet, nobody has to put efforts in it. Getting the Portage API would be
> nice too, so we can wait I think.

Agreed.

Regards
Dirk

--
gentoo-osx@gentoo.org mailing list

> > > Besides, I am more a fan of icon list views or OpenStep like multi-column
> > > lists, instead of table based lists...
> > I like the Finder giving you three views on the same data. For every
> > occasion it's own view ;)
>
> Which doesn't really help if you want to be GNUstep compatible. From what
> I know, on compatibility mode you are stuck with things like GNUstep
> Workspace.app.
> BTW, I believe finder is not written in ObjectiveC, so I am not quite sure
> if multi-mode lists are possible in Cocoa / OpenStep at all.

Hmmm... Not sure. I haven't toyed around with ProjectBuilder long
enough to know what you can do.

> > Why is a prefixed hierarchy (like Fink's /sw) not an option for you?
> > What is different in there from installing into /usr/local or /gnu?
>
> I think prefixed hierarchies make the system unclean. It is one thing if I
> decide to install modules into such a hierarchy in order to get
> interesting other modules compiled.
> It is a whole another thing if I want to let automated tools untidy my
> system ;)

So, what are your thoughts on using a Framework, like Apple does for
Java and Python for instance?

> I would think a working ObjectiveC compiler is a prerequisite for
> compiling gnustep.
> So perhaps gnustep-libs (or a meta package which could be solved by
> gnustep-libs-devel or cocoa libs) would be the correct dependency?

The gnustep ebuilds check if the compiler was built with the objc
USE-flag. This probably fails on OSX, since no compiler is built at all
currently.

> > > Good question, but something I cannot answer. My Python knowledge is
> > > nearly zero.
>
> > Same here. And I'm not enough attracted to the appearance of the
> > language to actually try and learn it. I can understand it, that's all.
>
> I don't really like the language either, but the possibility to write an
> portable application without either having to delve into proprietary XCode
> stuff, or into GNUmake build system hell, it becomes rather attractive.
> Its all a question of a comfortable tool chain...

Ehm... This might sound like blasphemy to some, but what about Java?
If cross-platformability is the only concern here, then Java does an
outstanding job, and has a very nice integration with the OSX interface.
Xcode/ProjectBuilder can even generate some sort of native compile of
Jaba code with UI widgets, which would probably allow it to speed up a
bit, while not entirely getting OSX only. Window manager would not be
an issue any more, and even Gentoo/Cygwin could benefit from it out of
the box.
In GUI's I'm not an expert, but for the rest of Java, I can handle it
fairly well.

Ok, no Java/Python/C flames here. Just practical comments please.

--
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
Sun Certified Programmer for the Java 2 Platform 1.4
--
gentoo-osx@gentoo.org mailing list

> > BTW, I believe finder is not written in ObjectiveC, so I am not quite
sure
> > if multi-mode lists are possible in Cocoa / OpenStep at all.

> Hmmm... Not sure. I haven't toyed around with ProjectBuilder long
> enough to know what you can do.

I am not sure ProjectBuilder is correct here. You mean InterfaceBuilder
(Apple) or GORM (GNUstep)?

> > It is a whole another thing if I want to let automated tools untidy my
> > system ;)

> So, what are your thoughts on using a Framework, like Apple does for
> Java and Python for instance?

I am not qute sure what you mean here. I know about frameworks as a Apple
/ OpenStep?) concept in general and really like it, but I don't know what
and how you would apply this to the current topic.
And I don't know about how to mix traditional Unix file system hierarchies
/ build systems with "modern" concepts like frameworks.

> > So perhaps gnustep-libs (or a meta package which could be solved by
> > gnustep-libs-devel or cocoa libs) would be the correct dependency?

> The gnustep ebuilds check if the compiler was built with the objc
> USE-flag. This probably fails on OSX, since no compiler is built at all
> currently.

I see. So in this case Gentoo is not of much use for building the wrapper.
Back to plain ./configure && make && make install, if any?

> > I don't really like the language either, but the possibility to write an
> > portable application without either having to delve into proprietary
XCode
> > stuff, or into GNUmake build system hell, it becomes rather attractive.
> > Its all a question of a comfortable tool chain...

> Ehm... This might sound like blasphemy to some, but what about Java?
> If cross-platformability is the only concern here, then Java does an
> outstanding job, and has a very nice integration with the OSX interface.
> Xcode/ProjectBuilder can even generate some sort of native compile of
> Jaba code with UI widgets, which would probably allow it to speed up a
> bit, while not entirely getting OSX only.

With cross-platform compatibility in this context I mean toolkit level
compatibility, i.e. a system which integrates nicely into the desktop.
And IDE specific builds just get in the way of having a build system for
both platforms.
I am neither able to use XCode on Linux (licence, binary only), nor
ProjectBuilder on MacOSX (withouut resorting to build the whole GNUstep
enironment on X)

> In GUI's I'm not an expert, but for the rest of Java, I can handle it
> fairly well.

Same as me (I am a certified Java developer too). Also purely non-GUI,
enterprise / server only.
But for the GUI side: last time I checked, there exist no maintained
Cocoa-Java bridge anymore (after Apple deprecated its work).
Even less a wrapper which works on both Macos and Linux.
And even if such thing would exists, it would be a wrapper library only,
which would make applications compiled against it less than platform
independent.
For (pure) Java toolkits like SWT and / or Swing - not on my (home)
desktop, please ;)

Regards
Dirk








--
gentoo-osx@gentoo.org mailing list

> But for the GUI side: last time I checked, there exist no maintained
> Cocoa-Java bridge anymore (after Apple deprecated its work).
> Even less a wrapper which works on both Macos and Linux.
> And even if such thing would exists, it would be a wrapper library only,
> which would make applications compiled against it less than platform
> independent.

I have to correct myself. There seem to exist JIGS, or GNUstep Java
Interface, e.g. at http://www.gnustep.it/jigs/index.html
.
(According to the project main page) the project aims to provide
integration between Java and Objective-C. Its main purpose is to allow
Java programmers to use the GNUstep libraries from Java.

That said, there exist a source code only (possibly dependent on a GNUstep
environment)
The package is not in portage, yet.
There seem to exist only one example (on the project page) which uses this
wrapper.

Regards
Dirk


--
gentoo-osx@gentoo.org mailing list

> > Fine. What is needed to get this started? I could try to compile / emerge
> > Renaissance and try to extract suitable flags for a Cocoa based ebuild.

> Sure! If you want to use it, (and it looks nice for Python people) we
> should first port it. Perhaps grab the patches from those that made it
> work on OSX, then see if we can put them in one ebuild, or need a
> separate one. Having compiling sources that's always useful.

Some updates:

- emerge gnustep-make compiles cleanly on ~ppc-macos. I used 1.100-r2
(1.10.1-pre20050312-r1 is package masked) I used USE="layout-osx-like"
- I compiled gnustep-make-1.11.1 manually into local hierarchy /gnustep.
Compile, make make install runs fine.
- Using one of both environments (not quite sure which) I build
renaissance 0.8, the latest version I found to download.
Building is just "source"-ing the the correct environment
XXX/Makefiles/GNUStep.sh, make and make install
Which went without problems.

So I assume at least a basic ebuild could be created.

Regards
Dirk
--
gentoo-osx@gentoo.org mailing list

On Sun, 27 Nov 2005, dirk.schoenberger@sz-online.de wrote:

> > > - image to vector applications like autotrace resp. potrace
>
> > Ok. Now I get what you want. For the image converting applications,
> > you might want to go for some 'drop file on' solution, like
> > Photoshop has. You simply drop a file on the icon, and it's being
> > converted somehow. I think this is quite generic somehow. Interesting!
>
> Nice idea, but currently not doable, I am afraid. My ObjectiveC / Cocoa
> knowledge is not upto task to do something as complicated as drag-and-drop
> programming ;)
>

When I used to use Fink, I wrote this script for viewing PostScript files
with Fink's ghostview (Preview.app under Jaguar wasn't able to open them).

http://www.telegraphics.com.au/~fthain/sw/launcher.applescript

To use it, just paste the script into Script Editor, change the PATH
variables, and save as application. You can then drop stuff on it from
finder and that stuff will get opened by gv in X11.

-f
--
gentoo-osx@gentoo.org mailing list

On 28-11-2005 18:36:39 +1100, Finn Thain wrote:
> > > Ok. Now I get what you want. For the image converting applications,
> > > you might want to go for some 'drop file on' solution, like
> > > Photoshop has. You simply drop a file on the icon, and it's being
> > > converted somehow. I think this is quite generic somehow. Interesting!
> >
> > Nice idea, but currently not doable, I am afraid. My ObjectiveC / Cocoa
> > knowledge is not upto task to do something as complicated as drag-and-drop
> > programming ;)
> >
>
> When I used to use Fink, I wrote this script for viewing PostScript files
> with Fink's ghostview (Preview.app under Jaguar wasn't able to open them).
>
> http://www.telegraphics.com.au/~fthain/sw/launcher.applescript
>
> To use it, just paste the script into Script Editor, change the PATH
> variables, and save as application. You can then drop stuff on it from
> finder and that stuff will get opened by gv in X11.

Yeah, thanks. This is exactly what I meant. Those kind of scripts are
easy to generate, and may come in handy. Question remains if this is a
job for us to do or not, and if so, how we would enable/disable it.

--
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
--
gentoo-osx@gentoo.org mailing list

On 27-11-2005 19:51:04 +0100, dirk.schoenberger@sz-online.de wrote:
> - emerge gnustep-make compiles cleanly on ~ppc-macos. I used 1.100-r2
> (1.10.1-pre20050312-r1 is package masked) I used USE="layout-osx-like"
> - I compiled gnustep-make-1.11.1 manually into local hierarchy /gnustep.
> Compile, make make install runs fine.
> - Using one of both environments (not quite sure which) I build
> renaissance 0.8, the latest version I found to download.
> Building is just "source"-ing the the correct environment
> XXX/Makefiles/GNUStep.sh, make and make install
> Which went without problems.
>
> So I assume at least a basic ebuild could be created.

There is an renaissance ebuild in gnustep-libs/renaissance. Did that
one fail?

Ok, this means keywording some of the GNUstep stuff then (where
possible) and making some contacts with the GNUstep maintainer fafhrd
(CC-ed on this mail), to see if he would like some some OSX
compatibility where necessary. Looking through the gnustep.eclass I
can't see problems directly. Armando, do you perhaps see any direct
problems ppc-macos will get when using the gnustep ebuilds?


--
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
--
gentoo-osx@gentoo.org mailing list

> On 27-11-2005 19:51:04 +0100, dirk.schoenberger@sz-online.de wrote:
>> - emerge gnustep-make compiles cleanly on ~ppc-macos. I used 1.100-r2
>> (1.10.1-pre20050312-r1 is package masked) I used USE="layout-osx-like"
>> - I compiled gnustep-make-1.11.1 manually into local hierarchy /gnustep.
>> Compile, make make install runs fine.
>> - Using one of both environments (not quite sure which) I build
>> renaissance 0.8, the latest version I found to download.
>> Building is just "source"-ing the the correct environment
>> XXX/Makefiles/GNUStep.sh, make and make install
>> Which went without problems.
>>
>> So I assume at least a basic ebuild could be created.
>
> There is an renaissance ebuild in gnustep-libs/renaissance. Did that
> one fail?
>

I looked at the ebuild, but it did rather strange and complicated things
(more than I think was needed)
After that and your last remarks about the check for objective-c in the
e-class, I did not continue working with the ebuild.

I don't want to keep the whole gnustep on my system, I have a working
substitute already, thank you very much ;)

Regards
Dirk
--
gentoo-osx@gentoo.org mailing list