Discussion: Subapps as Widgets and the Future

What does everyone think about the potential to use subapps as functional widgets?

The plus side is that all the objects would be in one package. The down side is that you have to use Global Values and Strings to communicate data, basically. However, the subapp can be visual for certain uses.

Also, now that we see that Widgets can be as useful as extensions are, what might we consider for the future? Should a future version of MMF allow for more specific ways to create Widgets that users can just plug into their apps and games? Do you have any ideas about the way you would like to see that implemented?

I am looking forward to ideas and discussion on this.

It could be useful to somebody....
A feature I would like is a Folder Object that you can copy files into and you would be able to give that a behaviour(to make multiwidgets better)

This is what me and Atom had to suggest on the future of widgets in a different thread a while back:

Quote:

---

Originally Posted by Atom

---------------------------------------------
Event Editor - Temp Instance Of Extensions
---------------------------------------------

I would like to see a way to make a temp instance of a extension in the event editor so one that is not required to be in a frame. This would allow you to make a widget that contains a extension etc so for example you could use something like 'Drag Object' and setup all of the events you needed inside the widget.

What this means is you would be able to save it to your library and instantly drag and drop the object complete with actions and ready to go right away rather than having to do it from the start or loading an example in and copying the code and extensions setups over into a frame each time.

---

Quote:

---

Originally Posted by Raylax

Widgets are obviously really helpful, but as Atom said, if they have multiple extensions and objects, they all need to be put into the frame manually. To speed things up, I think a new save file type, used exclusively for widgets, would be really handy. The creator of the widget would use Save As... > Widget (I'm just gonna use a non-existant *.wgt extension from now on). Then, the person wanting to use the widget would be able to use Import > Widget (or grab it from a special library). MMF2/3 would then go through the file, drop the necessary extensions onto the frame, then any actives with their behaivour(s).

---

Good thinking and on spot.

Already the idea is articulated well and sounds compelling. I think that helps support a potentially useful addition.

Ideas start the process, obviously.

I didn't deal with widgets very much before but the widget competition showed me that widgets could be very useful and this is a powerful feature of MMF2.

The idea what others said is really great. A widget file, or only a "Widget folder" that contains all of the neccessary extensions and objects for the widget would be good (and we could also change the icon of the folder...). Users had to put only the folder into the frame.

With these ideas, MMF2/MMF3 could be edited to load *.wgt files as extensions.

Another interesting idea would be to be able to mask say a value or string input for the widget and use it just like an extension in the events editor also. So you have behind the scenes a counter with 0 = off and 1 = on then in the editor you see something like Hide Shadow and Show Shadow or whatever you were doing so basically using the widget just like an extension object with simple to follow commands because you have this already to a degree with the alterable values etc but if you set up commands for inputs you would have to know what they were doing this would basically be just giving you a menu for this and making it a nice way to use values and widgets for dynamic input.

It also means that if the widgets already using internal values you wouldn't have to go inside and find the comment telling you what value does what and is like a visual mask that simplifies more complex input based widgets.

I have always had an idea for a program Clickteam could release. This program would allow you to use the features of other MMF extensions, create variables and menus, and then build a new MMF extension.

Can't you just use the Global Function object to send data if you have too many Global Values used up.

Quote:

---

Originally Posted by Jaffob

I have always had an idea for a program Clickteam could release. This program would allow you to use the features of other MMF extensions, create variables and menus, and then build a new MMF extension.

---

That would be awesome! Apart from it not actually helping anything...

Keep the ideas flowing. I think they get everyone thinking and then we start to make this more concrete.

Yes, a special widget feature might be good if it can be created without too much time and resources.

Imagining:

A special object or built-in feature/property.

If it were an object, you could use it just like an extension and have a set of specific variables and actions. It could be some sort of modification of the sub-app. In fact, what we are talking about sounds a lot like the sub-app ;) So, maybe that is a basis to work from both practically and technically?

So, perhaps the functionality is there, but the limitations become obvious. If we want a widget feature, then it would be like the subapp but more specialized.

Limits:

* Needs to have accessible variables that are not shared Globals. In other words, it would be like any object where you could send and retrieve data internally. Perhaps there is room here to have Variables that appear on the action list so they can be used like actions?

* Needs to be programmable and editable in the main application, as are Behaviors.

* Should have its own file format or extension so that you can save and load widgets, (maybe even drag and drop) specifically.

* MMF Widgets should be able to be closed or open "source". The author could provide the new functionality, but decide if the source is free to modify or closed.

* Widgets should have the capacity to be invisible, visible, or have a Shape Object like transparency. That way, if you designed a character with special movements, it could look and act like any Active Object. The same would apply if you had a special control element, etc.

* Oddball idea: Of course, we want the widget to contain extensions just like the subapp can, but how about allowing it to contain protected, internal extensions? I am think of industry here where a protected Widget could contain extensions that are exclusive and only available and usable in the Widget. That is to provide incentive for growth in 3rd-party offerings in the future.

Any more?

I think that the MMF Widget could have even more factors that have not been considered here yet. Remember that this is brainstorming, so oddball ideas are fine and I hope that users would refrain from criticizing or arguing about proposals at this stage.

This should be stickied to keep the conversation going.

this is a pretty good idea for making more complex widgets, but i'm not too enthusiastic about having the overhead from the subapp's frame

Czentnar's idea sounds pretty good though (maybe not really a "folder" as such, but just a collection of objects under one placeholder); it's difficult to make single-object widgets because extensions usually don't have sufficient capabilities for all you want to do, and having to make a multi-widget because you just need one expression from another extension (string tokenizer/parser, especially) sucks... being able to "group" multiple extensions under one "object" would be awesome

in fact, if you were able to define your own conditions/expressions/action menus (which run "macros" using that group's extension objects ACEs; you'd define them like you define the app's menu, and use similar 'menu option selected' conditions within the super-object's behavior) for that object group, that would be even better... so you're basically making one super-extension out of individual ones

EDIT: that was a horrible explanation but maybe you understand what i'm talking about

EDIT2: well i guess this might help
http://file.walagata.com/w/supermeta...jgroupmenu.PNG

I am glad to see such enthusiasm. Consider that fuel for the engine of a practical idea in progress.

If users see the potential of this once it became a reality, then it is obvious that MMF would have yet another path of extensibility and one that is more accessible to non-programmers.

Stickied!

We could use a feature that lets us open widgets in the New Object screen.....
Like this?

One thing i find with extensions sometimes it would be nice to set a default/start preset or setting without having to go into the events editor each time and speaking of that presets in general because some extensions can have various results esspecially if there graphics based so rather than having to save mutliple frames just for nice settings you simply have a editable name field and a dropdown of any presets and can edit these, if you could access those via the events also it becomes super powerful, say for any graphics extensions/widgets you can send a command to instantly change to a saved preset so rather than entering each value you do a single 'change preset to...' command and can have a super complex setup instantly called into action.

Also a GUI desigining option so you can have a basic menu with nice graphics etc or edit existing widgets. So rather than just a value edit if it was open and you wanted a slider it would be easy to replace with a slider etc.

We need grouping for things so you can lock multiple objects together, for things like a widget that had multiple parts this would be very handy especially if it was visuals. This for the main frame editing also.

Behavior switching, so you can setup a few behavior setups and switch between them via a event, so you could make 3 for example or have a Global Behavior for that object and switch between them, this would be another nice way of having presets but made by a developer or the user for any editables there was so you could setup a few control/movement types etc and then just use whichever you needed when it was right rather than saving lots of different widgets for that purpose.

I truly appreciate the discussion and ideas here.

The contest was also a great success and it is really good to see people's eyes open on the idea of an often overlooked method of extensibility.

As far as the ideas and suggestions coming in here go, we will certainly be taking this into consideration. The only problem with MMF3 is HOW MUCH we can add in a reasonable amount of time. At some point, we will have to prioritize what goes in MMF3, or is saved for 4, 5, etc. We have to balance how much time new features and such take to program with how important the features may be. Yes, a lot of features suggested to-date are very desirable, so that is why we will do what we can in version chunks.

I anticipate some acceleration, (excuse the pun) of MMF's development growth after JAVA and HWA are finalized. We will be working a more powerful, ready to expand upon base from there.

So, here is a question for those interested in this thread topic:

On a scale of 1-10, (ten being a must have) how would you rate the inclusion of various ideas above and more advanced, improved Widget creation capabilities in the next version of MMF? You can rate it based on your own "must haves" or also in relation to the larger base of requests you have come across by other users.

You could include reasons why or why not it is a priority and even ideas about what widgets you might create with more power to do so.

I think the idea that DarkeSoft said above would be important (6 or 7 from 10).
This is because users don't take the advantages of widgets but there would be lots of opportunities and easier programming solutions with them. So if widgets would stay nearer to the centre like extensions (for example we could choose one from a list like an extension and not only from the library, or the application would give more tips about creating widgets (I don't know exactly how much information is there in the help file), or an action in the event editor: make a widget from these events... (?) ).

I just posted in a different place praising widgets.

Yes, that's what I'd like. I'd use them as building blocks, or toys to put into my game.

e.g. someone made a bullet widget.
I used that to replace my rather poor basic shooting and bullet stuff.
It quickly allowed me to create a pistol, sniper, shotgun and potentially a flame-thrower style weapon.


I'd love the convenience of being able to view a list of widgets and choose what ones I want, or grab bits from them. Especially because people tend to provide a number of ready made examples of use for them, which I can just drag in and modify.

The extensions tend to be harder to get into as they are sometimes less well documented, and have no examples.

Here's how to more easily access widgets:

1. Go to your Multimedia Fusion 2 folder
2. Go to Lib\Objects from there
3. Make a folder called Widgets
4. Save the .mfa files with the widgets in there.

Thanks for posting that, DragonMC.

And thanks for your thoughts on the usefulness of Widgets, BREK.

There is certainly a future in them and as we continue to see new Widgets that will cement the idea in.

I am envisioning a future where, like extensions, Widgets will become more predominant, (and powerful) in future versions. It just seems logical and I am even surprised it has taken this long to get to the stage we are at and this forum area.

I wish widget creators were able to define a menu to control their widget, instead of passing parameters via alterable values and flags. If we could "code" a simple menu (more like cascading menus) to do simple things, like grouping the values together (such as "Position --> set x position to" would set Alterable Value A to whatever the user types there. Also, some "set glowing to on" would set flag 1 to on)... another cool thing would be an option in said menu to call a loop, or just inform the widget it has been selected so we could make functions.

And a more efficient way to do "multi-widgets" (group many objects into one that is customizable with the menu I said). That way we could use widgets as functions, and even call some neat "click-scripts" to do stuff for us...

That would really help remove clutter during programming... And it's real easy to code (I believe the menu could be coded into MMF in one day... maybe multi widgets in a week)

We have been pushing the Widget idea for a while and it is moving forward.

Thanks to users who are creating them, it is slowly starting to sink in. It takes time and patience.

Thanks for your ideas. I really hope that we will see some of the Widgeteers suggestions for making this easier to do, (and native in MMF) will make it into MMF3, at least.

I'm going to respond to the first question.

Quote:

---

Also, now that we see that Widgets can be as useful as extensions are, what might we consider for the future? Should a future version of MMF allow for more specific ways to create Widgets that users can just plug into their apps and games? Do you have any ideas about the way you would like to see that implemented?

---

It's pretty obvious what the optimal way to achieve this would be really. It's going to be slightly complicated to explain, but it's with no doubt the best solution.

Instead of just "Objects", I'd like to split those up in two separate parts. "Components" which are grouped into "Objects".

For example, the alterable values should be a component. The function of an Active object to display animations and store graphics should be a separate component too. All extensions should also be components. Then, if you e.g. group together an "Active" component with an "Alterable Values" component, you get an active object with alterable values. However, you'd also be able to group together an "Active" component with an "Array" component to create an active object with an array to hold it's values. You should be able to combine loads of components, e.g. several "Actives", into more complex objects.

Of course, it would be relatively easy this way to customize an object with behaviours to serve as advanced widges, since you can really pack as many different features you want into an object.

The main point of this is however how incredibly easy object selection with linked objects would be. If I'd mysteriously have to link an Active to an Ini, I could filter the entire object by an Ini related condition, and still perform the actual change to the Active component.

This basically gets rid of all fastloop usage that you have to use today to link objects together, and although I know that a few people who have figured out fastloops will go "use fastloops, they're really powerful", they're in fact really slow, particularily when a lot of them needs to be used, or when you need to iterate through a large number of objects. Imagine the uses, group a string over a active to get text with a graphical background (e.g. speech bubble) that can be treated as a single object, or group a bunch of body parts together to create a single enemy object.

Nifflas idea is wonderful

Alterable values position editor -

If you have alterables it's really annoying if you want to move them around or have values require notes etc. What i think would be nice is if there was a window/panel you could open via the 'values' with a edit list button that basically gave you the list of alterables for the object etc. Then you would click a alterable from the list and you could click a move up/down button or better yet just drag and drop it to change it's position. You could also name them all but without it showing in the main Values list so this way you could see the name when using events. For example your alterables list would be only values the user would need to edit but others you could use for maths and value storage etc.

Another useful thing would be to be able to give them a description, it would show where you see the title and then 'click to edit' and this way if you were making widgets you could describe what the value was doing. You could also describle to the user what value ranges to use or what a int vlaue would change etc. If this was added working with widgets would be really simple and much faster to make or edit them.

Also, furthering nifflas' idea, it would save memory for MMF, since some times you create actives as storage holders, and while they need arrays and alt. values, they don't need animations.

Same goes for collision detectors, health bars, bullets, and many other things actives are used for. A person will rarely use all the functions of all the active objects in their game. Stripping the unneeded functionalities depending on what you want from the object would save a ton of memory!