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 |