[rkward-devel] Upcoming release, call for testing RKWard 0.5.7

[Thomas Friedrichsmeier]

On Sunday 09 October 2011, meik michalke wrote:
> am Sonntag 09 Oktober 2011 (13:41) schrieb Thomas Friedrichsmeier:
> > On Sunday 09 October 2011, meik michalke wrote:
> > > we could change the name of the eventual meta file perhaps, like into
> > > "index.pluginmap", to make its purpose more obvious. maybe even i won't
> > > forget about it the next time, then...
> > 
> > or, perhaps we could reverse the convention. E.g. all .pluginmaps would
> > be included by default, except for those with names starting with "_" or
> > ".". That would still allwo plugin authors to "hide" some .pluginmaps,
> > without the  need to bundle all "official" plugins in a single map.
> 
> it would definitely have the same effect. i'd still prefer it the other way
> round, because it's more consistent with the way RKWard handles its own
> pluginmap collection already, so you don't have to learn something new when
> you want to work on plugins in the official release (e.g. integrate yours
> into it).

True. But of course that is up for discussion as well. In fact, that's where I 
think it will be particularly useful, once we have a re-desgined pluginmap 
configuration widget. Then users could finally select the pluginmaps we provide, 
individually. embedded.pluginmap and under_development.pluginmap would be 
renamed / hidden, all others would be visible and checked by default. After 
that, I think all.pluginmap (or any other index) will be pretty much obsolete. 
Do you disagree?

> btw, i might get my hands on a Mac at the end of the month, not brand-new
> but dedicated exclusively to porting RKWard. more on that when it actually
> happend...

Cool. Definitely looking forward to that!

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20111009/ceca2fa2/attachment.sig>