Hello Everyone!
It has been three weeks since my last blog post. In this post I would update
you with the current progress on the Calendar Application.
I have been working on the following since the past three weeks:
- Writing the Event and Category class.
- Working on UI of Event Manager.
- Working on UI of Category Manager and Category Edit Window.
- Working on a pop-up Calendar control to select event start and end date.
- Working on the Calendar View class to highlight the current system
date.
- Fixing bugs in the existing code and improvements.
- Working on Add/Modify/Delete events functionality.
- Exploring existing Haiku applications to look for widgets, trying to
implement new ones(For e.g DateTimeEdit - to select calendar start and end
date)
Add/Modify/Delete events
Basic Add/Modify/Delete events functionality is complete now. There has been
a little change from the initial mockups. Instead of switching views(I thought
of using the BCardLayout initially to switch been Day View and Add Event
section) and showing the Add Event section in the MainWindow, there will be a
separate Event Manager window for it. Event details such as Event's name, place,
description, start and end date/time can be filled. Also an event can be made
an all day event which will make it appear on the top of the Day View. Event
recurrence is not implemented currently and event category is not complete so
it's disabled for now. Because of not having a DateTimeEdit currently there's
just a text control that shows the date selected in Calendar View and a dummy
time. Also the calendar pop-up control is under work which would be a part of
DateTimeEdit. Currently, for storing purposes I am using BMessage and flat
files.
Hello again,
Sorry for late report, things are not going as I planned. In order to implement tree manipulation or copy-on-write function, I must first have a blocks/extents allocator that works well. Also, those things need to handle transactions as well.
In the previous weeks, I did some “edgy” works that are supported functions, add some on-disks structures, modify some parts of the source code, etc. Currently, I am implementing the extent allocator, it can now dump all the free extents and used extents for all roots, included backup roots. The goal is allocating continuous extents and preventing external fragmentation, but I’m stuck at it. My initial idea is using AVLTree that is existed in Haiku for tracking extents, and from that I can find a next necessary extent for allocating, but I’m not sure it is the right way. You can read all the works in my commit history[1].
Hey there, it's time for the monthly report again!
This report covers hrev51196-hrev51253.
Kernel
time_t now uses 64-bit on 64-bit systems. This fixes the year 2038 bug for
64-bit Haiku, so we can continue to run it after 2038.
This breaks the ABI, so all the 64bit packages were rebuilt.
Some bug fixes in packagefs, to avoid some annoying issues when updating the system
or repeatedly installing and uninstalling packages without rebooting.
Hello everyone. It's been substantial time since I started working on the project and here's the progress report.
On the reading end
Finally got over with reading the source code. What took it so long was that I first read most of the rfcs, including those I will be implementing even later on, before reading the current code. That kind of helped me not only to understand the code better but to also jot down the areas, where a change would have to be made, as and when encountering them. But then it consumed a lot of time as well.
Hello everyone! This report covers the span of the last two weeks of my porting efforts to get swift running on Haiku. I started debugging the runtime library ’libswiftCore’ on both Haiku and Linux and focused my attention specifically to the ImageInspection logic in order to fully understand how the runtime extracts ’type metadata’ from a swift generated shared object. My mentor korli, recommended me to use the get_next_image_info() function, which is the Haiku equivalent of iterating through the list of loaded libraries in a executable. Hence this, it was used to implement dl_iterate_phdr() in ImageInspection.cpp, taking some inspiration from the Cygwin port but parts were rewritten to be used on ELF based platforms.
Hi all,
This is my first post during the coding period of GSoC 2017. I have been working on a demo application which renders text using the harfbuzz library.The work on application started before the coding period. You can find the application here.
The work on application started before the coding period, but now the application is successfully running(Thanks to stippi!).
I pointed out few issues in one of my previous blog post. I have used the same words in Hindi for rendering in application. You will see that it is being rendered properly.
Hello World.
Now that we’re almost near to the first evaluation, and also it’s been 2 weeks since my last blog post. The last blog post had a plain vanilla GUI without any elements apart from the listview of the applications.
I worked on adding icons to the GUI, under respective categories. I’ve hardcoded the categorization part, after the first evaluation, I’ll work on categorizing the applications.
I used IconView.h along with some functions from LaunchBox. waddlesplash told me to go with BButton, so will be replacing the IconView with BButton soon as it provides easier handling of labels.
Hello Everyone!
In this post I would be focusing on the work done in the past two weeks,
issues faced and how I went about resolving them. Also, since the first
evaluation is near, the post also contains a brief analysis of the current
progress with respect to the deliverables mentioned in the proposal.
Issues faced and how I went about resolving them:
- I wasn't able to set the day names header in the calendar view based on
the locale preferences, the day names always showed up in English no matter
which language is selected in locale preferences. The Calendar view uses
BDate::ShortDayName() which in turn uses strfime to get the day of week
names, and it uses LC_TIME to decide which locale to use. By default it is
set to use the "C" locale set which is a rather neutral locale with minimal
locale information. In order to use the locale set selected in the
environment, setlocale(LC_ALL,"") has to be called. But still work has to be
done to update it with live changes in locale preferences.
<li>This was not an issue but still I have to look into several
implementations in order to find a proper way do this i.e updating the date
headers with changes in system date. I'm making the MainView in the calendar
app accept pulse messages(using B_PULSE_NEEDED) and every time the Pulse()
method is called I'm checking the system date and sending the state change
message using SendNotices() to all the other subscribers(currently there is
only one- SidePanelView that contains the date header and calendar views)
and calling the method to update the date header in the SidePanelView class
on receiving the message. Instead of using pulse, BMessageRunner can also be
used to send periodic messages.</li>
<li>There was a bit difficulty in updating the date headers and calendar
view day name headers with live changes in locale preferences as I was
unsure about how the handle B_LOCALE_CHANGED message. When locale preference
are changed BApplication gets the B_LOCALE_CHANGED message, I am forwarding
the message to SidePanelView and updating the headers based on the new locale
preferences. Work has to be done in updating the day name headers in the
calendar view on locale preferences change.</li>
<li>I explored the Haiku message-passing system in details and had a few
doubts regarding how to post and forward messages as there are similar ways
of doing itand used interchangeably in the existing applications. Stippi and
PulkoMandy helped me in understanding it better.</li>
<li>In the calendar view when I change the selected day, the current day
doesn't remain highlighted. Also if a day which is not in the current month
is selected, then I cannot bring the focus back to the current day
programmatically i.e the CalendarView::SetDate() doesn't work. I am working
to fix this.</li>
<p><img src="/files/blog/AkshayAgarwal007/calendar-focus.png" alt="Calendar"
class="img-responsive center-block"></p>
<li> This is more of a learning than an issue. Haiku uses a 32-bit time_t
and therefore is vulnerable to the Y2038 problem</li> So if events are set
to happen after the date 19-January-2038 3:14:08 AM GMT, they would cause
problems. Moreover the system date cannot be set to a date after Y2038
currently. Waddlesplash has recently worked to switch to a 64-bit time_t
and that is applicable for x86_64 build and not for 32-bit x86 and the Y2038
will remain the same for it. We will hopefully drop 32-bit support by 2038.
So for 32-bit x86 the calendar would not support dates after Jaunary 19th
2038.</li>
I also implemented preferences settings for the app. The user can enable/disable
week number and set the first day of week(which can be set to locale based first
day of week or any specific day.)
Greetings
Almost 2 weeks since the last Weekly Report, so here goes what I have been up to in the last two weeks.
Adding code
I am slowly adding new code as you might see here. Each commit represents a new file and its dependencies compiling successfully in my machine(gcc5). In asm/atomic.h I have commented out some of the functions which I believe is not required for DRM. If I find some use of those functions then I will have to revisit this file and make the necessary changes. Also, I have used some compiler (gcc5) functions in asm/atomic which will later have to be changed appropriately for use with gcc2 if that is desired.
Hello everyone,
I spent last 2 weeks mainly for researching and forming an complete idea so that something will not be changed much in the future and some coding. These things are what I did in the previous 2 weeks:
I implemented a “cat” command in btrfs_shell for testing, since current fs_shell misses read file content command.
Refixed ticket #127883. This is the ticket I fixed as a proof to attend GSoC for Haiku, but it is hardcoded. I simply changed the block size to node size (the old block size is sector size), so that block_cache can cache the whole node instead of caching multiple blocks with old block size, and reverted back the old code. I misunderstood in the past that block is sector but that is not always (at least in BtrFS case). In BtrFS, metadata is in tree block (node) and file data is in extent (a continous run of sectors), so with block_cache API I can easily manipulate tree node and with file_cache API for read/write files. I had a hard time to figure out how to write with cache, but after reading BFS and block_cache codebase, it can be done easily with memcpy for copying data to cache and block_cache_sync for flushing to disk.
