|Home | Project Home | Lists | Forums|
francaisFrancais DanskDansk
 
  March-15-2003 Meeting Summary

#slicker @ freenode.net
 
Moderator: uferlos   Transcriber: dasBOT
 
Present: |AV|Hellfire3k, billytwowilly, Blueroam, cmf, Curufinwe, danalien, dasBOT, derF, fantomik, George-, |Gimli|, illogic-in, kaosconman, Kobold, LBM, lucijan, mark, mpiper, NachoMan, RangerAway, russin, trappist, Ubel, uferlos, Verwilst
Email: RangerRick, Leinir, friedmud, John Hughes, Mark Bucciarelli, Markus Breitenberger, Martin Galpin
 
Topcis:
 
Log File Available here (which has been screened out of -joins -quits -parts -unrelated comment to topic, like what server should I connect to.... -and rearranged the text into topic/block).

And a tarball with comments from those who couldn't be there had to say is available here.

Greetings
Participants introduced themselves. They mentioned what they have been involved in, and what skills they have.

Conclusion: This information was used to start the Slicker Team Directory (not yet available, but soon).

 SlicKer or Slicker
Should we stick with 'SlicKer' as the project's name, or perhaps switch to 'Slicker', or 'slicker'.
  • The pun is obvious without the capitalisation.
  • The executable would be called slicker regardless of the capitlisation of app name.
  • Slicker looks a little more professional.
  • The K is not that important as long as the idea of what slicker is for is in the name, i.e, slick replacement for kicker.
  • Kaosconman volunteered to fix the main webpage graphic.
Conclusion: 'Slicker' was the majority preference and will now be the official project name.

 Theming
Theming - Qt / KDE / how should we proceed?
  • Qt/KDE theming would make sense, considering this is a KDE-oriented project.
  • Consider making QT/KDE theming compliance optional, not forgetting that doing so would mean extra coding.
  • If KDE themes, a theme based on the mock up could be attempted.
  • Perhaps a theme for just the slicker menu which all cards would inherit.
  • We want to make 'Slicker' look like the design mockups (fop's).
  • By following KDE's themes the look isn't as 'dynamic'.
  • Sticking to KDE themes will keep things simpler.
  • Consider how staying with KDE theming could affect (colouring, etc) using Slicker in other WMs.
  • KDE's integration is intentional, and to go outside of that framework would be redoing a lot of what has already been done, and making it harder for people to customize their desktops.
  • Remember X doesn't have have transparency yet. (wait for x to implement that is the question?)
  • We should keep it simple, though keep it as user-configureable as possible.
  • Volentiers to be involved in Theming (both creating and coding)? (Kobold volentiers)
  • We should worry more about making Slicker usable and have a good underlying framework than themes; rather have something that works well than is crappy but pretty
    • Wasn't the whole point of slicker to both more usable and more attractive at the same time, than the current menu system
  • If the wheel would roll better why not re-invent?
    • slicker pretty much is re-inventing the wheel isn't it? isn't that the point?
    • We don't need to re-invent anything. Just provide one (qt?) theme for slicker that it is installed with. Then if the person so desires they can choose to use whatever kde uses.
    • In that case, would it not be better to make changes to kdecore than in an add-on app? Don't have a problem with re-inventing wheels, but rather putting the wheels in the wrong place.
    • More usable and attractive, yes; but I we need to re-invent the wheel to do it?
  • Have slicker have it's own (fops mockup) theme that slicker keeps unless the person decides to switch "turn on" accepting others.
  • We could go for (fops) mockup theme (including colour scheme, otherwise it follows kdes and doesn't look as 'dynamic') minus the transparency.
  • To go outside of KDE's framework would be:
      • a) redoing a lot of what has already been done, and
      b) making it harder for people to customize their desktops.
  • If we have an option of going to KDEs theme then there is no customization lost.
  • If we use kdes current colour scheme then all the cards will have the same colour, but if we implement our own colour scheme, then we have control.
    • You can put it in a Qt theme.
    • It should probably be pointed out that kicker has extra colour settings above kde's as well.
    • Some colours should be taken from the default theme, such as the colour of the slider thing and the default colour of cards, but that these should be overwriteable.
    • Use as many colours as possible from KDE, and let slicker define the rest (like the tiles in kicker).
    • Can we extend them to provide colors for different screen elements? By contributing patches to KDE that just add additional Slicker-specific color settings.
  • Keep things simple, rather focus on adding functionality and keeping things fast, than worrying about theme compatibility.
  • Should borders on card be an option?
  • It just makes sense that whatever we use should not take a lot of relearning by people who have already written other KDE-based themes.
  • Make a QT theme, distribute it with Slicker. And let people choose wether:
      • a) they want to use the KDE standard theme.
      b) they want to use the Slicker theme.
      c) they want to use a completely different theme
    (You choose a theme from a drop-down box).
  • If we don't worry about the theming problem now it will be a PITA to implement later.
  • Work more with KDE core and figure this out.
  • Would the card's apptitle conform to the titlebar theming? or none at all?
  • Theming Slicker could be done the same way as everything else.
    • You have a button widget, or you have a card. In order to do this, all the widget themes would have to be extended to know how draw slicker elements, this could pay off.
  • Conceptually separating Slicker from the rest of KDE, by calling it an "app", etc, is a bad idea.
  • One thing that would be nice to see are coloured card tabs, but that is already a wishlist item.
  • Make desktop-independence and cross-platform a primary consideration.
  • Stick consistant to the rest of KDE. Either by creating our own theme, or a set of overloaded widgets which conform to the UI that is drawn out on the homepage. This way all developers will be using the same widgets for all applets and we'll get a nice consistancy feel in the applets.
Conclusion: All seem to agree to make Slicker look as in fop's mockups, so the path we choose really won't matter, as long as we stay commited to the idea and add additional options/features so an end-user can still choose to have it his/her way. Though for our first theme we should try out different approaches, and see which method/way comes closest to fop's mockups, and see where that will lead us down the road...

 SourceForge Tools
sf.net tools - yes or no.
  • Yes, would want to use them, but only if there is someone maintainning them.
  • Yes, bug system tracker.
  • Bugs useful, tasks not.
  • Only useful if there is someone constantly policing them.
  • Someone willing to step up and be the "bug/feature request/foo" maintainer who will forward bugs and feature requests to the proper place?
  • Someone should put a message on the forum that most discussion has moved to #slicker@irc.freenode.net.
  • Rather have the forum (via homepage) on the mailing list.
  • While our CVS is on sf.net, why not?
  • Yes for bugs and tasks. have bug and task entries mailed to this list.
Conclusion: We use for now the bug system. As soon as the database is filling up we will discuss a bug-lieutnat, who will be in charge who knows whom to assign and clear bugs. And if there is someone willing to step up and take care of one of the tools, speak out.

 RPMS
Should we be releasing precompiled binaries yet?
  • We'll decide releases when we're ready, home compiled rpm's of CVS snapshots aren't veyr useful at this stage
  • "if you can't read and understand how to get the cvs than slicker isn't for you now" (uferlos).
  • "From a user standpoint, the documentation is quite adequate to get slicker from CVS, in case anyone wants a user opinion" (billytwowilly).
  • Well, until we decide to put betas out
  • Maybe dip into the new upcoming package managers ie autopackage?
  • Eventually? Yes. Now? No. Not at this point
  • When the time comes, bin's for as many distrumitons we can make.
Conclusion: Short version "Not yet"; at this point in time, and that we should wait until we've got _something_ and then go and make them.

 Menu Modifications
Should we make the attempt to simplify the menu system similar to the Mock Ups? Conclusion: Uferlos will look into what's technical possible with the Menu, we need simplification of the menus. how to achieve that isn't really clear yet.

Usability research
Could you help? How should we proceed? Conclusion: Most dev's can chip-in and help and do the research.

Release Plan
What should be our goals for releases? What functionality and time range?
  • We release when mark decides ;) <-- *this is a joke!*
  • Included the ability to hide/show by keypress (with configurable key/key-combination).
  • Add: "Hide to background" (not allways on top).
  • Write specifications on what slicker *is* (documentation).
  • When the Slider is somewhat stable:
    • Have the K Menu using Task Oriented Menu first as well, if we are going to do that.
    • The first Freshmeat.net and LinuxApps.com announcements should be made.
    • Still, no binaries, only a source distribution, no version number but with a date (slicker-cvs-17032003.tar.bz2 or somesuch).
    • First binary release (0.1) should happen after a second meeting when it is decided what applets and such should be included.
  • "I don't think we need a release plan at this point" (John Hughes).
  • When the time comes a] Release early and often, or b](debian's) release when it's ready.
  • In a future release (not decided), incorporate the 'rolodex'-behavior into slicker.
    • Quick summary of 'rolodex': You can move cards over each other, and they get "stack over each other", where you use the mousewheel to roll thru the stack.
  • Devised a test strategy before making a release. how to test? Write a text doc with step-by-step scenarios.
  • 1. Function, 2. Stability, 3. Design.
  • Just get it to work first, then we can decide.
Conclusion: No realease plan, not yet. :-), first iorn out what slicker is/should do and then code it - stable!. Then, statoil! :-)

 Core Imporvements/Additions
What additions are needed for the core?
  • Rewritting the plugin thing to be CardApplet central, rather than Card central basically (by mark).
  • Change of how the config system works (by mark).
  • Add/remake a new/the card loader menu.
  • No applet should be allowed to take down Slicker.
  • A set of "slicker widgets" that we could use to try to impose our style on the cards.
  • More work done on preferences.
  • Optimizations for the drawing code (by Derek Gaston).
  • Working done on reducing duplicated code by creating common classes (by John Hughes).
  • Adding support for Xinerama (by John Hughes).
  • Some gui/usability guidelines.
  • The slicKer bar.
Conclusion: Progress is beeing made on 45% of the core work, need additional developer help coding unsigned work.

 KMenu Card
Mark needs help making the KMenuApplett work properly without a custom Tab.
  • The problem:
    • Don't receive the QMouseEvent:: for the click that is closing the menu
    • Its the fact that QPopupMenus aren't designed for how we're using it
  • I will take a look if I get time (Derek Gaston).
  • I'll see what I can do (Martin Galpin).
Conclusion: illogic-in, Derek Gaston, Martin Galpin are looking into it under marks supervision :-)

 What next...
What should be the focus for the next steps in the project - new core, add more applets, close bugs?
  • Fix bug in system tray applet (needs to be reloaded at startup)
  • Fix Launcher applet
    • underlines things when everything else doesn't
    • doesnt have a drag box
    • (after multi cards) doesn't auto align oralign cards at all (onstartup all my icons are on top of each other!)
    • can't be resized for some reason (on some system[s]?)
    • have same thing in them as current ones (on some system[s]?)
  • For a non coder this would be a good opportunity to do some work:
    contact all authors if they want to put their stuff in cvs. POLITELY PLEASE.
  • Important to make sure the core is stable - not only in runtime but that the API is fairly solid so that there arent' a lot of rewrites of card functionality down the line because of moving targets
  • Overall more core work - Improve the code "Zakariya" gave us.
  • Devise a list of "core" applets which we need inorder for a first release. Then, the applet developers can be delegated an applet and we wouldn't all be wondering what todo next.
Conclusion: Lots of things to be done

  
 
SourceForge Logo