Mudlet features and API requests
Re: Mudlet features and API requests
Use <br> in a label.
-
- Posts: 97
- Joined: Wed Jul 25, 2012 12:35 pm
Re: Mudlet features and API requests
How to do it? Example please
English is not my native language. If you don't understand what im writing ask.
Ubuntu 17.04, Mudlet 3.1
Ubuntu 17.04, Mudlet 3.1
Re: Mudlet features and API requests
testlabel:echo("one line<br>another line")
Re: Mudlet features and API requests
Haven't gone digging, as this was a toilet thought. Is there any way to put the notes functionality into a label/miniconsole? If not, that's something I and others would find handy since it would allow for a scratchpad to easily be implemented to store info people want to scribble down or see at a glance that is really changeable.
- SlySven
- Posts: 1023
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Mudlet features and API requests
<aside>I hope you made sure you wash your hands after...!</aside> The data is stored in the "notes.txt" file in the root of the profile's directory tree so you could always read and write it via lua file handling code stuff - though it is stored as a UTF-8 file. A quick check did reveal that the reader code {in the C++ method dlgNotepad::restore()} did not close the QFile that it creates to read in the contents - and the code that writes out the data when you close the "notes" window will overwrite the existing file; so if you are going to fiddle with the file yourself you want to tell the user when it is safe for them to have the "notes" window open (NOT while you are changing the file).
Mind you, the notes functionality is already there "to store info people want to scribble down or see at a glance that is really changeable" - just not one that can be customised to fit into a scripted/customisable part of a GUI - or is that what you want?
Mind you, the notes functionality is already there "to store info people want to scribble down or see at a glance that is really changeable" - just not one that can be customised to fit into a scripted/customisable part of a GUI - or is that what you want?
Re: Mudlet features and API requests
Fitting into a GUI is exactly what I'm looking for. Figured why recode if the functionality is already there. Is no big deal, I can write a simple, terribly optimized scratch pad. But having the user able to click on a GUI window, and just write something, would be nice instead of aliases and the like.
-
- Posts: 27
- Joined: Fri Jun 26, 2015 8:52 am
Re: Mudlet features and API requests
[ ALERT ] - Socket got disconnected.
English grammar dictates that this should be "Socket was disconnected."
On a more serious note I would love an option in the settings menu to set the location of the profiles directory. I know that things like the symlink workaround exist, but this seems like overkill if its possible to just have Mudlet look for files in a different location. I travel a lot right now and it would be really awesome if all I had to do to use Mudlet were to pop in a flash drive and open the executable.
English grammar dictates that this should be "Socket was disconnected."
On a more serious note I would love an option in the settings menu to set the location of the profiles directory. I know that things like the symlink workaround exist, but this seems like overkill if its possible to just have Mudlet look for files in a different location. I travel a lot right now and it would be really awesome if all I had to do to use Mudlet were to pop in a flash drive and open the executable.
- SlySven
- Posts: 1023
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Mudlet features and API requests
I did a quick check in the source and found the equivalent of QDir::homeDir() + "/.config/mudlet/profiles/" is used in lots {where lots is significantly more than ten} of places! From a coding point of view I agree that perhaps the "profiles" directory might usefully be a variable - though extending this to further up the directory structure for ALL of Mudlet's stuff could give us a chicken and egg situation where the location that stores the data would be stored in a file (the Mudlet main "QSetting" file mudlet.ini) which needs to be readable to FIND the location before you can read from it...!
-
- Posts: 27
- Joined: Fri Jun 26, 2015 8:52 am
Re: Mudlet features and API requests
I'm speaking from a position of ignorance, so sorry if this is nonsense, but wouldn't it be best to put the location of the settings files as early as possible in the hierarchy? Any time I've coded something that relies on a configuration file to determine its behavior, I've put that file in the same directory (or sub-directory) as the executable and then had the program read settings from the file as early as I could. I also haven't written anything terribly large, so I may be misunderstanding the problem.
- SlySven
- Posts: 1023
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Mudlet features and API requests
That doesn't always apply for OS specific file configuration locations - and it also depends on whether the settings are for a particular user or for the application's use independent of who is currently running it {of course if more than one person is using it on the same system simultaneously that also makes some things more complex}
As it happens we currently assume that the Mudlet application is configured for each user independently of any other - so the use of a sub-directory of the almost hidden ~/.config/ directory is the right thing for *nix environments, but I'm not quite so clear on how things are for other platforms...
As it happens we currently assume that the Mudlet application is configured for each user independently of any other - so the use of a sub-directory of the almost hidden ~/.config/ directory is the right thing for *nix environments, but I'm not quite so clear on how things are for other platforms...