Just a reminder to developers:
If you write up a good promotional article explaining why your program is uniquely suited for running widgets I'll put it together in a general "Widget software" guide.
It is going to be important that AveDesk, Samurize, Kapsules, etc. build up their followings lest a year from now users are using Konfabulator for Windows.
"Help me help you!" 
C'mon now, it's not a bad thing if people use Konfabulator. There's no need for any harsh competition. Just look how (relatively) well 3 docks get along at AquaSoft. People will always have a bias towards certain apps, even if others are technically better. Many people will use Avedesk because it's developed "in house" here, for example.
If you're going to write a Widget guide though, be sure to talk about how Apple invented them with Desk Accessories, since lots of people are pissed at Apple because of the whole Konfabulator mess.
http://en.wikipedia.org/wiki/Desk_accessories
http://www.folklore.org/StoryView.py?proje...k_Ornaments.txt
This shouldn't be here though...
Apple didn't invent widgets.
The modern concept of end user created mini-applications came with DesktopX and was further moved forward by Konfabualtor.
I'm quite familiar with the latest case of Apple retroactively "inventing" something. Desk accessories are no more the forerunning to widgets than Microsoft's Windows accessories.
The whole point of of widgets, in the modern sense, is end user created mini-applets that live on your desktop without requiring some software developer to sit down with a low level programming language to first create them.
So no, I won't talk about how Apple invented them because they didn't. Dashboard was (at best) inspired by Konfabulator.
As for "harsh" competition, please don't put words in my mouth. As a registered user of Konfabulator and a very vocal defender of it on Konfabulator's websites, I am not anti-Konfabulator.
However, as someone who knows something about the software market, I do know that the Windows indie developers could use more exposure. I would consider it preferable that it be AveDesk or Samurize or Kapsules or DesktopX, as native Windows programs, that people use over a MacOS port.
And Konfabulator has been able to get a lot of media attention thus far.
I also don't see why this post had to be moved from the DesktopX area and into some general area when the discussion on putting together this article started in the DesktopX area and was linked to from the home page.
@BPP: What's wrong with promoting software? Frogboy has all reason to promote DesktopX, because (in no particular order) a) It makes him and his company money, 
A new version is out, c) He's proud of "his" product. Also, the better the free widgets apps are settled for Windows, the harder it will be for konfabulator to take over the Windows-widget-market. I think that's also an aspect Frogboy is having in his (marketing)mind .
@cuddles ( 
): Apple did not invent widgets. From what I read in that wiki, those so-called desktop accessories, is rather a (binary) standard for global, systemwide plugins, but I just had a quick peek.
Anyhow, my personal opinion is that there isn't a program "uniquely suited for running widgets". I myself like to run multiple widget applications.
Also, I don't think 99,5% of the users care about widgets created in low-level languages. Hell, they don't care about the implementation, Object Model, the number of pencils used in the development process. What most people want are widgets that work like expected, are configurable to some extent, and are easy to set up.
Another question that rises - which you already mentioned at least once - is how many unique widgets are there? If I browse thru the konfabulator galery I see endless pages of little variations of one and the same concept: clock this, clock this with that, clock in that color, a green clock, a blue clock. A webcam that monitors japan, a webcam that monitors antartica, a webcam that monitors my basement... The question is, is it better to have 100 different widgets that do the same thing but with a different look, or on 1 widget that can have 100 different looks?
I will try to write a "good, promotional article" about AveDesk this week, but it's time to play some soccer again :soccer:
PS. While you are here Frogboy, I'm having the issue with DesktopX2.2 that, whenever I mouse over a button or click a button, move an object, the entire object seem to flicker for a short period. very annoying for my eyes :cry: Any ideas?
1. I cleaned up the offtopic/flamey posts here.
2. Frogboy: You misunderstood me (or I worded my post poorly). A few things:
- I wasn't saying you or anyone else was competing harshly, I was saying it shouldn't come to that, and I've seen it happen with friendly developers. This was a warning to everyone, not specifically to you.
- Obviously there will be a difference of opinion on "widgets", but it's clear that they all descended from Apple's Desk Accessories. This wasn't my point though. If you're going to write a Widget guide, you should include some history. Not just Apple's work, but the entire evolution. It's simply a good idea when writing any article to include some background about the subject you are discussing.
The whole point of of widgets, in the modern sense, is end user created mini-applets that live on your desktop without requiring some software developer to sit down with a low level programming language to first create them.
You did just make up your own definition of widget though, so it's easy to be "right" when you do that. Even then, Desk Accessories are mini-applets that live on your desktop, and can be written in Pascal. I'd say Pascal was pretty high level for the time.
- Sure the apps could use more exposure, and more power to you. I was just warning people against becoming "zealots" for one app. This was a harmless warning about being objective, nothing too original. For example, you think AveDesk et al are better because they're native rather than ports. I don't understand this attitude, and it stinks of bias. If the port is technically fine, why is that a bad thing? Seems like a Mac vs PC argument.
- This was moved from the DesktopX section because it's not about DesktopX. Simple.
Moved to community applications (where it belongs) because it directly address's applications created by members of this community. Leave it here.
In addition, this topic has been pinned... free publicity from a guy that gets quoted in "Time" and "Wired" magazines is an outstanding offer.
deadzombie
Yeah, this is a better place for it. I just knew it shouldn't be in DesktopX. I guess I'm still old school, this forum layout confuses the **** out of me.
Cuddles:
1) Widgets are NOT from desktop accessories. Apple's desktop accessories have nothing to do with widgets.
I've written at length on this last month:
http://draginol.joeuser.com/index.asp?AID=22370
2) I don't know about developers not getting along. I can't imagine Andreas or anyone else being "harsh" with anyone. We're on the same side.
3) As Andreas correctly points out, my "marketing" view on this is that ALL the native Windows widget enabling apps need more exposure. My job isn't simply to push Stardock stuff. It is to push WINDOWS customization. And I think it would be a bad thing for the community if it appeared that we needed Apple ISVs to "show us how it's done".
Andreas and the others are not competing on a fair playing field. Konfabulator has gotten massive free publicity in the past. And when a Windows version comes out, it will get more.
I would like to see AveDesk and Samurize and Kapsules (and of course DesktopX) to get their fair share of coverage.
4) I also agree with Andreas on Konfabulator widgets. There's essentially 11 main widgets for Konfabulators with the rest being derivatives. They are certainly done very well and very slickly.
5) In terms of widget history, I'm going to start where modern widgets, as a concept got started: OpenDoc and Taligent. As for definitions, yes, the person who writes the articles get to define the term. Feel free to write your own article defining widget however you'd like. But I can assure you that the definition I've given is by far the more widely understood term in the customization community at this point (mac or pc). Just like the term "skin" means something different to us in the customization community than it means to say my neighbor or a porn star .
If you look up "widget" in the dictionary you will find that mini-application doesn't come up. Apple didn't refer to desk accessories as widgets either. In the customization community, the term widget has a very specific meaning -- mini-applications created by end users. This definition remains the same whether you're tlaking to me, or Arlo or any of the others.
And since we're on Aqua-Soft, the term widget does mean something here and it means (and I'm pretty sure nearly everyone will agree with this) specificaly mini-applications that can be created by end users. As opposed to say a limited function program written in 68k assembly language.
6) And yes, when it comes to ISVs, I tend to favor the home team. Andreas and co. were working on this stuff while Arlo was out touting the Mac. Good for Arlo but yea, I'm going to choose Andreas's work over Arlo's on the PC. It's not that I'm anti-Mac, like I said, I'm a reigstered (i.e. I've paid my own money) for Konfabulator.
But at the end of the day, I'm not keen on letting Mac uesrs have the upper hand in defining where widgets are going. It's bad enough that there's people running around giving Apple credit for widgets.
I first remember reading about widgets being customizable controls on X server environement back in 94 or something like that, usually QT widgets.
so if we go that way widgets should be customizable mini controls (or mini applications with customizable controls )
Originally posted by Alderaic@Aug 24 2004, 03:12 PMI first remember reading about widgets being customizable controls on X server environement back in 94 or something like that, usually QT widgets.
so if we go that way widgets should be customizable mini controls (or mini applications with customizable controls )
<{POST_SNAPBACK}>
The term "widget" goes back a long time. Words mean different things in different contents.
We use the word "skin" all the time. And when we use that term we understand that the word has been used for other things in the past. But here in this context we know that the word skin means a collection of images used to change the visual appearance of something.
Similarly, in customization, the term widget refers to mini-applications that can be created by third parties that make use of an enabling program (Konfabulator, DesktopX, AveDesk, Samurize, Kapsules).
I didn't coin the term widget. We started out using the word "object" (which is even MORE generic ).
Hhahaha, Judge, I didn't knew you were so obsessed with this stuff in 1990 already that you had to name your cat after it 
anyhow, I would like to throw another definition of widget (not judge's cat) in:
Originally posted by myselfa (graphical) freeform object placed on the desktop that usually performs one single, small task (mini-application).
Good examples of widgets for the Windows platform are weather forecasts, e-mailcheckers/notifiers and analogue clocks.
The only problem I have with that definition is that any number of small regular programs would fit that.
What is the different between WinAmp and AveTunes for instance?
In my mind, the difference is that AveTunes doesn't have the overhead of Winamp because it is relying on AveDesk's framework.
Widgets, IMO, are different because they have less overhead than a typical stand alone program of equal complexity and are designed to be created by end users.
Winamp doesn't perform one single, small task. It's a full blown media player which can play all kinds of media: I wouldn't consider a media-player as a small task.
The difference between Winamp and Avetunes is pretty easy: Winamp plays the music (and does have a graphical output) where AveTunes only shows information about the music.
One might add the notion that widgets usually require a host application/framework to run - In the case of DesktopX Pro not.
Originally posted by AndreasV@Aug 24 2004, 11:26 PMOne might add the notion that widgets usually require a host application/framework to run - In the case of DesktopX Pro not.
<{POST_SNAPBACK}>
well I would not add that notion, clocks are full aplications, airport level too, weather etc... they rely on something but well then everything relies on the OS or on something 
I'd always put widgets to be 'the UI-thing that came after desktop icons'.
I wouldn't consider any of the samples Alderaic named as full applications,
just as mere icon enhancements that managed to escape the task bar's 16x16
or the desktops 32x32 pixel limit...
Remeber Windows 3.x, anyone?
Each window would minimize itself to an icon on the desktop, which you could
move around and doubleclick to restore. It had no context menu, no label,
no nothing.
Recently added features were context menus, labels, tooltips and state changes,
as a dial-up shortcut would change between connected and disconnected states.
Some of them moved into the tray and with Windows 95, the task icons became
ugly header controls with a 16x16 pixel limit, while on NextStep and OpenStep
they remained icons and were stacked somehow into a strip which their sibling,
Mac OS X, managed to animate and enhance so well that developers from all
around the globe asked themselves 'how come we have been enduring MSs
half heartedly updated shell restrictions so long?'
So why were desktop icons getting more and more interactive in the first place?
It must have something to do with the retreat of pure C programming and
the acceptance of more object oriented approaches in OS and UI design. Now, the
icon has become an object, that relates to, delegates from, incorporates or views
another object. I think widgets will swallow and replace static desktop
icons until the third dimension enhances our still flattened user interfaces.
(I'm expecting the third dimension to enter displays as well)
I believe that we'll have to wait until the entire desktop becomes an OpenGL or
DirectX scene and the bread and butter frame windows degress to real time
texture providers before we can really get widgets flying and not only floating;
so answering the original intent of this thread: None of the above. Not yet,
because of mostly technical reasons:
- DesktopX suffers from its 95/98 origins and its premier 'legacy' millstone of
rendering OLE controls, which won't render on layered windows or DirectX
surfaces
- Kapsules burdens itself with the gap between the dotNet runtime and 'legacy'
ActiveX scripting instead of hosting dotNet widgets
- AveDesk doesn't yet know what it wants to be when it's grown up
- Samurize is as chaotically uneven in its limits and possibilities as any Delphi app
- Konfabulator will lose most of its widgets because of platform dependencies
- All of the above not being ready for 3D and the implications Avalon is bringing up
Finally, I wish a 3D desktop with widget support was built into the system but I
guess Longhorn will disappoint me in that matter. So, if there isn't any support
for that, the best strategy would be to overtake the entire desktop rendering at
graphics driver level. This can only come from MS, since other's extensions
won't coin a standard.
Yes I agree.
I wonder about Avalon too. How big the the leap in desktop customisation term will be?
What I wonder is how hard is it going to be to skin Longhorn. As far as I have heard, the final interface will use vectors. Which I'm sure will limit a lot of VS/WB designers as the leap from creating raster to vector will be too big for some.
Well, vector drawing has always been a part of windows.
Remember the crappy .wmf and .emf files that took space on your MS Office
installs? These are just recorded drawing instructions and were kind of orphaned
during the move from 16- to 32-bit Windows. It's about time that they get a
facelift including the funky 32-bit per pixel alpha, gradient fills etc and most of
all: a better scaling algorithm. Since they always have been and will continue
to be able to draw embedded raster images and notwithstanding MS's capability
to remain compatible, there is less to fear IMHO.
Originally posted by Septimus@Aug 28 2004, 09:27 AMWhat I wonder is how hard is it going to be to skin Longhorn. As far as I have heard, the final interface will use vectors. Which I'm sure will limit a lot of VS/WB designers as the leap from creating raster to vector will be too big for some.
<{POST_SNAPBACK}>
Perhaps not so much "leap" as simply "completely and utterly different."
Stuff like the brushed style in panther immediately becomes bloated in size and processor because of all the lines it's trying to draw, etc. etc. I hope Microsoft doesn't abandon raster completely in Avalon because of this sort of thing.
Then again, we're dragging the topic off topic.
I was trying to write down a definition for widgets, so I tried to find out what makes them different from common apps...
Widgets differ from normal apps in UI: while the window of a common app should conform to the guidelines provided by the operating system, widgets are allowed to ignore them completely.
Common applications, by following the OS rules, have the right to be as simple or as complicated as they want... the end user will always be able to find his way around, easily. Widgets, on the other hand, are forced to be as simple as possible. The price for having a different look, is to keep it as straightforward as possible; the user will see something different, but it should not be confusing or hard to operate.
Simplicity of a widget's UI means simplicity of its capabilities. A widget can't have more than just a few functions. That's why Winamp cannot be named a widget: it has a simple interface with less than 10 functions, but it has a lot more functions hidden under right-click menus and buttons (playlist, equalizer, etc).
Finally, widgets are (often, but not necessarily) the evolution of gadgets and real-life objects, for the computer: the calendar hanging on the wall, a business card holder, a thermometer, a post-it note, a clock.
I guess the first widget I've ever seen is that old-fashioned calculator in OS 8.
Have a nice day!
Ken
Where to download Konfabulator for Windows? is it released?
nope, it's not released yet
OK, this thread has been dormant for a while, but since this affects the future of almost all widget machines:
Considering the overall future of widget apps in general, there is a new issue arising. A lot of these apps are besed on the windows scripting host which now seems to have seen 'end of development' at Microsoft:
(Qutation from news://msnews.microsoft.com:119/OZqCIy8tEH...ftngp13.phx.gbl)I must say, I am extremely surprised, especially considering that> VbScript does handle OUT and IN, OUT parameters. I hope that this is
> something that will be consider in the next release of JScript.
AFAIK there will be no next release of the COM based JScript or VBScript
engines or of the COM based script hosts.
If you want a flavor of what comes next, join the MSH (aka MONAD) beta...
Jeffrey Snover - Monad explained
Finally, Microsofts future scripting system will be .Net based.
This should not frighten the average user since its a long time to go, but for the developers of widget apps another well introduced technology has been buried alive without a reason - no more upgrades for the script engine, no better documentation for the script debugger interfaces, performance issues with COM/Interop not solved. 
Curiously, Konfabulator comes out of this mess totally unimpressed: its JavaScript engine spawns from the Netscape/Mozilla/Firefox breed and is hence immune to Microsoft decisions - another "using Open Source pays"!
Kapsules being written in .Net may have to consider recoding its scripting engine bindings from WSH to MSH in the long run but this will be a bargain offer to its ".Netness" anyway.
DesktopX is seemingly not that dependant on scripting that it wouldn't easily lift support for an additional scripting engine. Correct me if I am wrong.
AveDesk utilizes scripting for its effectlets but can live without it as well. The Win32'ness is the bigger problem here. The same applies to SysStats.
Samurize uses scripts in its most primitive form - I guess it would not even notice if MSH replaces WSH - provided MS would be smart enough to port the MS Script Control.
dotWidget is based on abandoned technology anyway: VB6
This is just another side aspect of MS's .Net initiative - COM/ActiveX and Active Scripting won't die overnight but slowly ooze into to the fossilizing "legacy" subsystems and be there for all your retrocomputing needs.
Just to throw my two cents in... I'm not sure that the idea of a widget as an easily created mini-application really matters. In my experience you have power-users who don't mind looking under the hood and tweaking XML or some custom scripting language and "point-and-click" users (these having no desire to open a text file ever in their life). These "point-and-click" users come in two flavors... those that couldn't give a #*$& what their desktop looks like and those that love to skin/customize. But either way, the "point-and-click" users aren't going to do anything more than install a widget that someone else wrote. So I guess what I'm trying to say is that even if you come up with a somewhat simple user interface to create and customize widgets, I'm not convinced it would prove to be of much use. Call me a skeptic...
The big question is if this would affect the end-user or the developer, IMO. I agree with jef about the different types of users, and if the code is already created, it's not too difficult to find what you want and tweak it.
Around when will this become an issue?
-NC
Aqua-Soft Forums