Gentoo Archives: gentoo-osx

From: Grobian <grobian@g.o>
To: gentoo-osx@l.g.o
Subject: Re: [gentoo-osx] Followup to: The road ahead?
Date: Sun, 27 Nov 2005 14:04:15
Message-Id: 20051127140348.GI10941@gentoo.org
In Reply to: Re: [gentoo-osx] Followup to: The road ahead? by dirk.schoenberger@sz-online.de
1 On 27-11-2005 14:32:56 +0100, dirk.schoenberger@×××××××××.de wrote:
2 > > > - image to vector applications like autotrace resp. potrace
3 >
4 > > Ok. Now I get what you want. For the image converting applications,
5 > > you might want to go for some 'drop file on' solution, like
6 > > Photoshop has. You simply drop a file on the icon, and it's being
7 > > converted somehow. I think this is quite generic somehow. Interesting!
8 >
9 > Nice idea, but currently not doable, I am afraid. My ObjectiveC / Cocoa
10 > knowledge is not upto task to do something as complicated as drag-and-drop
11 > programming ;)
12
13 I think the OS is your big friend here. If I'm not mistaken a drop
14 action is equal to typing on the command line:
15 open -a <app being dropped on> <file you dropped>
16
17 > > For sure! But aren't there attempts for this yet? I mean, is this idea
18 > > brand new, or are there already a few apps that are some sort of skin
19 > > for ImageMagick, but just written in something that doesn't work very
20 > > well on OSX?
21 >
22 > Most (GUI) attempts I know try to wrap around the Image Magick API and try
23 > to build a document centric (or a type manager / image database)
24 > For document centric there exists GraphicConverter, while for type manager
25 > there exist iPhoto.
26 > Both are not really interesting to me.
27 >
28 > What I miss on Mac is something like IrfanView's (on Windows) batch
29 > conversion GUI.
30
31 Ok. Question then is how Gentoo specific this is. Such application
32 would more or less sound like something which has it's own ebuild and
33 depends on imagemagick.
34
35 > I think Automator is a dead end, at least currently.
36 > - Tiger only
37 > - only linear workflows
38 > - I have not so many recurring tasks which would require building automator
39 > like workflows.
40
41 Ok.
42
43 > > > - a simple list where you can see the list of latest ebuild changes,
44 > > > something like "keep your system uptodate"
45 >
46 > > Like the FinkCommander screen, right?
47 >
48 > In fact more something like that ;) http://www.gnomejournal.org/images/45.png
49
50 Ah... (a lot) like SoftwareUpdate, or a tiny little bit like MS Windows Update.
51
52 > > > I have never seen FinkCommander
53 >
54 > > Good, good, good!!!! :) However, you should take a look at their
55 > > screenshots, because it's exactly what you describe.
56 >
57 > FinkCommander seems to be a good candidate for a "data waste / information
58 > overload" type application. I don't think such a GUI is really suitable
59 you got it!
60 > for a large repository like Gentoo, with thousands of applications.
61 I think their repo is larger at the moment, but it sucks, yes.
62 > Besides, I am more a fan of icon list views or OpenStep like multi-column
63 > lists, instead of table based lists...
64 I like the Finder giving you three views on the same data. For every
65 occasion it's own view ;)
66
67 > > OT: did you install Python 2.4 in the end?
68 >
69 > No. If I currently need source packages which are not available for
70 > Gentoo, I either install manually into /usr/local, or into really parallel
71 > branches like /gnu.
72 > progressive mode, or a Fink style managed /sw hierarchy, ar currently no
73 > option for me.
74
75 Why is a prefixed hierarchy (like Fink's /sw) not an option for you?
76 What is different in there from installing into /usr/local or /gnu?
77
78 > > The keyword aqua comes to mind... Kito and I had a discussion about it
79 > > the other day, but the idea is right I think.
80 >
81 > Fine. What is needed to get this started? I could try to compile / emerge
82 > Renaissance and try to extract suitable flags for a Cocoa based ebuild.
83
84 Sure! If you want to use it, (and it looks nice for Python people) we
85 should first port it. Perhaps grab the patches from those that made it
86 work on OSX, then see if we can put them in one ebuild, or need a
87 separate one. Having compiling sources that's always useful.
88
89 > > Sure. Objective-C is just something which you should have compiled when
90 > > emerging gcc, but GNUstep users (like me, surprise, eh?) will probably
91 > > be able to benefit from these efforts.
92 >
93 > I would much prefer to be able to use a package.provided ObjectiveC
94 > compiler...
95
96 You already have one. But Linux users by default don't.
97
98 > > Question remains who else could benefit from it, because the number of
99 > > Gentoo/GNUstep users is rather small, IMHO.
100 >
101 > Good question, but something I cannot answer. My Python knowledge is
102 > nearly zero.
103
104 Same here. And I'm not enough attracted to the appearance of the
105 language to actually try and learn it. I can understand it, that's all.
106
107 > > If I recall correctly, there are special eclasses that for instance
108 > > allow to place an icon on the desktop of the user (transparently to what
109 > > window manager the user uses).
110 >
111 > If you use py2app, you get a app folder in the dist sub folder of your
112 > python app root. I thought it was a good idea to copy this app folder
113 > application into something like /Applications/Gentoo, in the installation
114 > step of emerge.
115 > No need to toy around with links, at least not on OSX, I think.
116
117 Hmmm... that's indeed interesting.
118
119 > > The GentooUI (pronounced as 'gentoo-e' ? :p ), or iGentoo can be
120 > > developed in a separate track from the others. However, it would be a
121 > > waste if it would be developed such that nothing of it can be reused for
122 > > other Gentoo/X projects.
123 >
124 > Agreed on the "separate track".
125 > I am not quite sure about the other part. From what I see, a GentooUI tool
126 > (or at list something like a FinkCommander clone) is not much more than a
127 > emerge output parser and pretty printer ;)
128 > This means that the interesting / backend parts are already re-useable
129 > (even more so if there exist an API instead of having to grep console
130 > output), while the frontend part mostly are toolkit specific and not
131 > useable.
132
133 I follow your reasoning, and agree with it. I personally think this is
134 not very important to have right now, so if nobody feels like doing it
135 yet, nobody has to put efforts in it. Getting the Portage API would be
136 nice too, so we can wait I think.
137
138 --
139 Fabian Groffen
140 Gentoo for Mac OS X Project -- Interim Lead
141 --
142 gentoo-osx@g.o mailing list