Difference between revisions of "AfterStep Wish List"

From AfterWiki
Jump to navigationJump to search
(New page: == Introduction == The following is a Wish List (AfterWish?) of features for future versions of AfterStep. == Wish List == '''Better TwinView/Xinerama support.:''' Where AS does not pl...)
 
Line 5: Line 5:
  
 
== Wish List ==
 
== Wish List ==
 +
 +
 +
Theming : stuff missing - sasha plz correct this:
 +
<ul>
 +
<li> ability to define a border when swallowing applets, so button can be x/y pixels wider then swallowed content, so growing systrays can still look nice</li>
 +
<li> ability to install all config files and maybe combine default and themed version</li>
 +
</ul>
  
 
'''Better TwinView/Xinerama support.:''' Where AS does not place windows in the middle of multiple monitors. So windows aren't showing half on one
 
'''Better TwinView/Xinerama support.:''' Where AS does not place windows in the middle of multiple monitors. So windows aren't showing half on one

Revision as of 14:11, 29 February 2012

Introduction

The following is a Wish List (AfterWish?) of features for future versions of AfterStep.


Wish List

Theming : stuff missing - sasha plz correct this:

  • ability to define a border when swallowing applets, so button can be x/y pixels wider then swallowed content, so growing systrays can still look nice
  • ability to install all config files and maybe combine default and themed version

Better TwinView/Xinerama support.: Where AS does not place windows in the middle of multiple monitors. So windows aren't showing half on one monitor and half on another.

Add Enable/Disable Image Expansion Preview in "Menu Options": The option to expand image previews while holding the mouse over the menu item is a rather "hidden" feature. Add this to the Menu_Options so users can experiment with it.

Multiple WinLists: no ability to start multiple times with different content.

inherit windowboxes: ability to inherit windowboxes (some way to have more automated placement -> ion)

Forms: Ceased functioning in AfterStep 2.0. Who can make this work again?

Sound: Let's add some sounds for events. AfterStep has been quiet for too long.

DONE! Ready for release in 2.2.5. Ability to Scale Icons in Wharf: Either a function like SmallMiniPixmap, where each icon can be scaled individually (WharfMiniPixmap?) or as a group like ForceSize (ForceIconSize?).

Advantages: Currently in Wharf, icons need to be resized individually through Gimp as images, or xml scripts need to be created for each icon image. Either way, additional files need to be added to AS or to the User's HOME directory. The additional files mean that custom Wharf configurations with smaller icon sets (32 x 32, for example) would need the icon sets transferred with them. Having an icon resize funtion would allow the use of all existing AS icons and transferring custom Wharf scripts would be as easy as copying the single Wharf text file.

A user building a 48x48 Wharf could draw equally from icons in normal/ and large/ icon folders without concern of the icon being cropped. Users building even smaller Wharfs for 640x480 or 800x600 displays (24x24 or 32x32) could also use any available icon.

Of course, Applets/DockApps would be excluded, as most are set to 64x64 only.


Notification module: I agree that systray icon for application that are window managed is rather useless. But with the new applications like gnome-power-manager and network-manager, a notification module would be very useful. These apps only appear in the notification area and have precious features. The only correct solution for now is to run trayer. Having a module that fits with the rest of AS look would be nice.


Cropping with Wharf: How about cropping an area of an applet/dockapp for viewing in Wharf?

Most Applets/Dockapps are fixed at 64x64. If I have a 32x32 Wharf (48x48, 24x24, some triangular setup, whatever), there is no effective way of viewing the output of these applications. If Wharf could crop a user-defined window size, offset X and Y distance across the Applet, and display that output in a Wharf button, most if not all applets would be available for all users.

Example: wmclockmon is a fixed 64x64 Applet. I could define a window 51x22 pixels, horizontally offset 7 pixels to the right and 8 pixels down vertically. The output could then be directed to a horizontal 24x24 Wharf using MaxSwallow.

Maybe this isn't do-able. Dunno. That's why it's a wish list :) (Unless it gets moved to the "Ain't Gonna Happen List).